Note: This post was revised on April 4, 2022, to provide a comprehensive copy of the Client Incentive Program specifics.
A variety of clients is essential for the vitality and decentralization of the Ethereum network. This diversity fosters ongoing innovation at the foundational layer of the protocol, strengthens the network against potential attacks or bugs, and engages a wide spectrum of participants in discussions regarding possible changes to the core protocol.
Although clients play a crucial role for the network (without them, the network cannot function!), they have traditionally found it challenging to derive value. Recently, new avenues for these teams to establish viable businesses have emerged, but most of these are centered around mainnet-adjacent opportunities rather than the primary Ethereum network. Moreover, these options typically do not scale in relation to the value generated.
To ensure that client teams maintain robust incentives to support the core Ethereum network over the long term, the Ethereum Foundation has introduced a Client Incentive Program. This initiative provides client teams with rewards in ETH that are unlocked over time, contingent upon their continued development of software that meets the performance and security standards of the mainnet.
In particular, participating teams will receive a total of 144 validators (4608 ETH) each for use on the mainnet. The magnitude of these grants acknowledges both the exceptional work accomplished in recent years and the numerous development challenges anticipated in the foreseeable future. One team, whose client has become mainnet-compatible more recently than its counterparts, has been granted a 50% stake. The teams participating in the program include, in alphabetical order:
- Erigon
- Go-ethereum (geth)
- Hyperledger Besu
- Lighthouse
- Lodestar (50% stake)
- Nethermind
- Nimbus
- Prysm
- Teku
Validator deposits are made upfront for the teams to operate immediately. However, the withdrawal credentials (ownership of the funds) will vest over several years, with the initial tranche unlocked following the implementation of Beacon Chain withdrawals. To receive this and subsequent tranches of validator withdrawal credentials, teams must continue maintaining their clients, meet performance benchmarks on the mainnet, and actively contribute to the evolving Ethereum community roadmap. Post-Merge, client teams will also earn transaction fees collected by their validators. Along with staking rewards, this will initiate a stable revenue stream for the teams.
As the grants vest, teams are allowed to manage the validators under their control as they see fit – for instance, they may continue to stake and earn rewards, withdraw and liquidate, or adopt a combination of both. Additionally, the Client Incentive Program is supplementary to any grants already provided by the EF to these teams.
A complete copy of the program’s specifics has been attached as an appendix below.
Geth’s unique situation stems from its status as a team within the Ethereum Foundation. However, like the other listed clients, the Geth team will have full discretion over how to utilize the validators, earned fees, and ETH deposits as the grants vest.
The program’s structure aligns teams with the long-term health of the network, ensuring they are motivated to develop secure and efficient software. It was crafted to recognize past performance and reward teams that have already contributed production-quality software. We hope this lays a foundation for effectively incentivizing core contributors to Ethereum. As always, the Ecosystem Support Program is available and eager to fund earlier innovative Ethereum implementation initiatives, including new client teams.
We are thrilled to publicly unveil this initiative, and we look forward to discovering more ways for the community to unite and support public goods!
Client Incentive Program Details
Given the total amount of ETH earmarked for distribution to client teams (approximately 42,000 ETH when factoring in validator rewards, or over $145MM in value as of April 4, 2022), we understand the community’s desire for more information regarding how distributions will occur and how milestones will be achieved.
Below are the complete details of the incentive program as communicated to client teams.
Program Goals & Eligibility
The program aims to provide enduring support and incentives to teams for maintaining reliable clients and overall network health.
To qualify for the program, client teams must already be contributing to the broader development of Ethereum and plan to support the forthcoming shift to proof of stake. Throughout the program, teams will need to maintain specific performance levels to retain eligibility for rewards. Further details are provided below.
Configuration
| Name | Value | Description |
|---|---|---|
| NUM_PERFORMANCE | 128 | Count of validators monitored for performance |
| NUM_CANARIES | 16 | Count of canary validators |
| NUM_VALIDATORS | NUM_PERFORMANCE + NUM_CANARIES | Total number of validators |
| INITIAL_RELEASE | 32 | Count of validators released at the initial major milestone |
| TIMED_RELEASES | [6, 10, 14, 18, 22, 26 + NUM_CANARIES] | Count of validators to be released every 6 months after INITIAL_RELEASE |
| METRICS_WINDOW | 8192 | Count of epochs over which success metrics are evaluated |
| MAX_PROBATION_WINDOW | 32768 | Maximum epochs a Client can be on probation before the EF can partially or fully remove them from the incentivization |
Structure
Outlined below are the high-level actions undertaken by both the “EF” and the “Client” throughout the duration of this plan.
- Deposit creation
- Transfer control of active signing keys
- Client manages nodes/validators
- Release withdrawal credentials in phases
1. Deposit creation
Once a client agrees to join the program, the EF establishes NUM_VALIDATORS 32-ETH deposits.
The total ETH at stake in the client incentivization initiative amounts to NUM_VALIDATORS * 32.
In collaboration with client teams, a formal commencement date for this program will be defined, expected to fall between October 1, 2021, and the occurrence of The Merge.
2. Transfer of control of active signing keys
Post step 1, there will be NUM_VALIDATORS private keys corresponding to the public keys within the validator deposits, all controlled by a single mnemonic. It is crucial that these keys are securely handed over to the client team.
The mnemonic will be transferred to the Client via one of the following approaches:
- Utilizing asymmetric encryption (e.g., PGP) using the known/validated public key of the recipient Client
- Verbal transmission in 25% segments over 4 secure calls on varying platforms
- Through an alternatively negotiated, secure method
Following this, the Client will generate NUM_VALIDATORS keystores using the mnemonic and confirm each private key sequentially aligns with the batch of validator public key deposits registered in their name.
The EF will retain the mnemonic in cold storage as a backup in case the active keys are needed to withdraw validators from the program.
3. Client manages nodes/validators
Deposits have been created; keys have been transferred. Now, the Client is responsible for managing the associated validators until the withdrawal credential private keys are released. Notably, the Client must utilize their own software as an execution engine or consensus layer and must ensure ongoing support for a corresponding client throughout the incentivization timeframe.
The performance of the Client’s validators can be evaluated by simply reviewing chain metrics, though additional node performance data may be requested.
4. Release sets of withdrawal credentials upon reaching milestones
Validators will be released to the Client in waves upon meeting predetermined milestones via the transfer of the underlying private keys for the validator withdrawal credentials.
When a wave of validators is released, it concludes the Client’s obligations to the EF concerning those validators. The Client is then free to choose whether to continue validating, exit, withdraw, etc.
These keys will be encrypted with PGP and transmitted in batches.
Milestones
Given the dynamic nature of Ethereum’s evolving roadmap, simplicity is prioritized in establishing milestones.
A set of credentials will be released upon the enabling of withdrawals from the beacon chain, requiring a minimum interval of one year between the initiation of the Client Incentive Program (CIP) and the complete rollout of the first wave of credentials.
Should withdrawals from the beacon chain be enabled within or prior to the first year of the CIP, the first wave of credentials will be released monthly, in equal installments, from the first month after withdrawals are initiated, up to the one-year mark of the program. For illustration, if withdrawals are enabled six months after the start of the program, then one-sixth of the first tranche will be released during the months 6 through 12. Otherwise, the initial wave of credentials will be unlocked when withdrawals are enabled. Additional waves will be released over time as the Client continues to meet expectations. Specifically, the milestones are as follows:
- Release INITIAL_RELEASE validators once withdrawals from the beacon chain are enabled (WITHDRAWALS_ENABLED_TIME).
- for i, num_validators in enumerate(TIMED_RELEASES), release num_validators validators at time WITHDRAWALS_ENABLED_TIME + (i + 1) * 6_months if client operation continues to display successful metrics.
Success metrics
Client/validator performance must continually meet a set of success metrics to maintain participation in this program.
The first NUM_PERFORMANCE validators of the deposited validators are monitored by the EF for performance metrics. The last NUM_CANARIES validators are available for the Client’s use in testing, experimental releases, etc. Note that canary validators are not required to consistently meet the success metrics but remain subject to slashing rules.
Metrics
| Name | Value | Description |
|---|---|---|
| MIN_ACCEPTABLE_BALANCE | 31.75 ETH | Minimum acceptable balance for client validators |
| MIN_ATTESTATION_PERCENTAGE | 95 percent | Minimum acceptable percentage of attestations generated by client validators |
| MIN_BLOCK_PERCENTAGE | 95 percent | Minimum acceptable percentage of blocks generated by client validators |
The following are the success metrics that the Client must achieve:
- Client validators, on average, do not fall below the MIN_ACCEPTABLE_BALANCE balance
- Client validators maintain at least a MIN_ATTESTATION_PERCENTAGE percentage of expected attestations included on-chain during any METRICS_WINDOW epoch period
- Client validators achieve at least a MIN_BLOCK_PERCENTAGE percentage of expected blocks included on-chain over any METRICS_WINDOW epoch period
Additionally, client teams are expected to actively engage in the research and development of significant network upgrades. The EF solely determines whether this metric has been fulfilled.
Above all, the EF expects client teams to work diligently toward maintaining a resilient and healthy network. The EF acknowledges that certain circumstances may render these metrics beyond the Client’s control (e.g., a significant portion of the network being offline for an extended duration due to issues with another client). In most such instances, the METRICS_WINDOW has been designed to be sufficiently long to accommodate issues and recovery. Nevertheless, in remarkable situations, the EF will also consider external factors that lie outside the Client’s influence.
Note: For the purposes of this plan, validator top-ups are prohibited and should generally be avoided. If a scenario arises in which a top-up would be beneficial for the network’s health, the EF and the client may discuss and readjust the metrics/milestones accordingly.
Probation
Should the Client fall below the success metrics, their incentivization status will transition into a probationary phase. During the probationary period, the Client has a maximum of MAX_PROBATION_WINDOW epochs to restore metrics to successful standards. During this time, the Client will not receive any validator credentials. The duration spent in probation will delay the release of any validator credentials by a period that is at least that length of time.
If Client metrics remain in a probationary state for more than MAX_PROBATION_WINDOW epochs, the EF may, at its discretion, partially or entirely remove the Client from the incentivization program and may also partially or fully withdraw the Client’s validators.
Slashing
In the instance where one or more of a Client’s validators is slashed, such a validator will be excluded from the incentive program.
Should the slashing event be relatively isolated and promptly addressed, the EF retains the right to reinstate up to 16 of the slashed ETH per slashed validator back into the program, to be released at the final milestone.
In cases of a widespread slashing event that is negligent or recurring, the EF may, at its discretion, partially or fully remove the Client from the incentivization program and also partly or entirely withdraw the Client’s validators.
Note: Performance and canary validators are both subject to the slashing rules.
Cross-Layer Dependencies
While the Client fully bears the responsibility for ensuring their operations are performed in a performant and non-slashable manner, we acknowledge that there are limits to what execution or consensus layer teams can do to alleviate issues in other layers. Specifically, we expect clients to follow best practices with respect to managing their nodes but will not penalize them in the event of a widespread issue induced by the other layer. Optimal practices for operating validators include:
- Ensuring the Client can interoperate with the majority/all primary clients, especially on canary validators;
- Guaranteeing that the Client’s failures are decorrelated from the rest of the network, by relying on a variety of clients and hosting configurations;
- Ideally ensuring that the Client’s counterpart nodes are distributed across more than one client to mitigate issues specific to a client;
- Ensuring that the Client is capable of switching from one counterpart client to another in the event of a client-specific issue.
Terms
This plan is an opt-in additional incentivization scheme for clients. Participation in this plan, as well as the amount of locked funds within it, will not influence future decisions regarding client grants. Clients can include a minor budget for node infrastructure in grant requests, regardless of their involvement.
Prerequisites for joining this plan include successful participation in multi-client testnets and consistently demonstrating production readiness.
Furthermore, particularly in the context of extraordinary and unforeseen scenarios that involve the client, the client team, the Ethereum roadmap, and/or the Ethereum mainnet, the EF holds the exclusive right to decide how to allocate withdrawal credentials and/or modify the terms of this incentive plan at any time.
Exceptional circumstances encompass, but are not limited to, the following:
- Separate client teams merging into a single entity
- Client team splitting into two distinct teams
- Client team discontinuing the maintenance of a component (e.g., validator client) or the entirety of their software
- A significant change to the Ethereum roadmap that renders the current milestones unattainable
- Prolonged issues with stability, finality, or other operational functions of the Ethereum mainnet
- A contentious hard fork occurring on the Ethereum mainnet
