--- tags: besu-cip --- # [WIP DRAFT] Besu Client Incentive Program, Proposal #4 This proposal extends the original [Besu Execution Client Incentive Program (CIP)]('https://hackmd.io/@timbeiko/besu-cip') to take into account the fact that Hyperledger Besu, unlike other client teams on Ethereum, is maintained by multiple organizations under the Hyperledger Foundation umbrella. **Note 🚨: this is a WIP document, subject to changes, meant to explain the overall structure of the program. This is _not_ a formal grant or other legal agreement.** [toc] ## Guiding Principles 1. As with the original program, the Ethereum Foundation (EF) reserves the right to change, update or terminate the program at any point. The EF thus acts as a check and balance that Besu maintainers, their parent organizations, and the Hyperledger Foundation (HLF) continue to meet the requirements of the program. 2. The program offers teams locked ETH in the form of live validators to be released according to certain milestones. Alongside the "principal" (i.e. locked ETH) portion of the program, teams' validators will also accrue staking rewards and transaction fees. 3. While fees & rewards should be shared across the entire set of Besu maintainers working on mainnet, access to the locked ETH is reserved for organizations who demonstrate longstanding support for Besu's mainnet work and the Ethereum network generally. ## Notable Changes At a high level, this proposal departs from proposals [3](https://wiki.hyperledger.org/pages/viewpage.action?pageId=62236988) and [3.5](https://wiki.hyperledger.org/pages/viewpage.action?pageId=62237321) in the following ways: * A more explicit delineation between the roles of mainnet maintainers (MM), patron maintainers (PM), and patron organizations (PO); * Transaction fees are sent to a splitter contract rather than to a set of different addresses, in order to simplify validator management and remove the need for transfering excess fees received across organizations; * Transaction fees for a vesting period are sent based on contributions in the previous period, rather than the current one. This is to have a weighted list of addresses at the start of each period which can be inputed in the splitter contract; * Withdrawal Key distributions look at contributions in each period rather than the sum of historical contribution, with the exception that the first distribution is exclusively split between ConsenSys and the Hyperledger Foundation to recognize their historical contributions to Besu. ## Definitions ### Ethereum Mainnet Development Ethereum Mainnet development work includes (without limitation) contributions to features, performance, and stability required for Ethereum Mainnet operation of the Besu client. This work includes supporting work necessarily deriving from this effort, such as build maintenance, code cleanup, documentation, test maintenance and development, etc. This includes work on EIPs and proposals in AllCoreDevs intended for Ethereum Mainnet deployment, up until such a time as they are known to be excluded from Ethereum Mainnet deployment. Excluded is work relating to Ethereum Classic development, GoQuorum compatibility, private transactions, private transaction enclaves, permissioning, etc., and supporting work deriving exclusively from these activities. ### Contributors, Maintainers, Patrons #### Contributor An individual contributing to Hyperledger Besu who is not listed as an [active maintainer](https://github.com/hyperledger/besu/blob/main/MAINTAINERS.md). Contributors are **not** directly eligible for any share of transaction fees, validator rewards or withdrawal key distributions in the program. #### Mainnet Maintainer (MM) A contributor to Besu who **is** listed as an [active maintainer](https://github.com/hyperledger/besu/blob/main/MAINTAINERS.md) and whose contributions are focused on Ethereum Mainnet Development, as defined above. MMs and their employers are eligible for a share of transaction fees and validator rewards (see "Mainnet Maintainer Pool (60%)" below), but are **not** eligible for withdrawal key distributions. MMs are expected to have at least one substantial contribution to Ethereum Mainnet Development during a Vesting Period to be eligible for a share of transaction fees and validator rewards. Examples of substantial contributions include the implementation of new features relevant to mainnet (e.g. sync, complex EIPs), significant performance improvements, criticial security fixes, etc. #### Patron Maintainer (PM) A mainnet maintainer whom the EF has, to its sole discretion, identified as meeting the Patron Eligibility requirements (defined below). PMs and their employers are eligible for a share of transaction fee and validator rewards. Additionally, if a PM's employer is **not** a Patron Organization, the PM's contributions will count towards withdrawal credentials vested to the Hyperledger Foundation (see "Withdrawal Keys Distribution"). An organization which employs PMs can make a request to the EF to become a Patron Organization. #### Patron Organization (PO) An organization which employs PMs and whom the EF has, to its sole discretion, identified as meeting the Patron Eligibility requirements (defined below). POs are eligible for a share of transaction fee, validator rewards and withdrawal keys based on their PM's contributions to Ethereum Mainnet Development, as defined in "Mainnet Maintainer Pool (60%)" and "Withdrawal Keys Distribution" below. At the start of the program, only ConsenSys and the Hyperledger Foundation are considered POs. ### Node Operator The organization(s) in charge of operating the validators. At the start of the program, ConsenSys will operate all 144 validators included in the program. The EF can make a decision on whether to change that structure at any point and invite a new party to also run the validators. Input from HLF and the Besu community will be considered, but the EF reserves full discretion over operator selection. Factors considered when selecting node operators include: * General technical experise; * Experience custodying sensitive cryptocurrency keys; * Proximity to client maintainers, both Besu and others, to share learnings & suggestions and diagnose mainnet issues. ### Keys There are three types of keys that are being managed in this process: Withdrawal Keys, Block Signing Keys and Transaction Fee Keys. #### Withdrawal Keys The withdrawal keys have control over the validators’ principal and rewards upon withdrawal. Note: partial withdrawals (e.g. only rewards, and not principal) will be possible after keys are vested. These keys are initially held by the EF and over time transfered to Patrons, as per the schedule outlined in the CIP. Note: these cannot be updated and **loss of these keys results in full loss of validator funds.** #### Block Signing Keys These keys, held by the node operator, are used by the validator to sign consensus messages, such as blocks, attestations and exits. The node operator can lose funds by either omitting to sign consensus messages, if offline, or signing invalid messages (e.g. contradicting blocks), leading to more severe penalties, called "slashings". #### Transaction Fee Keys These keys have control over "legacy" (i.e. Eth1/execution layer) Ethereum addresses which receive the transaction fees associated with block production. Unlike Withdrawal or Block signing keys, these can easily and rapidly be updated by the node operator. ### CIP Vesting Period The time between two withdrawal key releases in the CIP. The first vesting period runs from the start of the program (when validator deposits have activated on the beacon chain) to the first withdrawal key release after withdrawals from the Beacon Chain are enabled. Subsequent periods are 6 months in duration. ## Transaction Fees & Validator Rewards Distribution The proceeds of the validators operations (i.e. transaction fees and rewards) will be split into three pools: 20% to the node operator, 20% to HLF as a directed donation for a "Besu Community Fund", and 60% to a mainnet maintainer pool. To facilitate the distribution across multiple parties, a splitter contract (such as, for example, [Mirror Splits](https://dev.mirror.xyz/mQ03-JXlfdoBnRrZisC5X3kM9nBkOILlHwxbdq382Gw) ([Github](https://github.com/mirror-xyz/splits))) will be used during each vesting period for validators to transfer transaction fees to. This will allow transactions to automatically be split according to each pool's share. #### Transaction Fees vs. Validator Rewards Transaction Fees are available to all validators post-Merge without any vesting or required withdrawal procedure, and are collected on Ethereum's execution layer (e.g. Eth1, or a "legacy" Ethereum address). Validator rewards accrue to validators on the consensus layer and require a partial validator withdrawal to be spendable on the execution layer. These will only be available to be distributed once their associated withdrawal keys have vested. Patron Organizations, who receive validator withdrawal keys, are expected to, at least once per vesting period, transfer accrued fees to the splitter contract. If liquidating their validator, POs are expected to distribute accrued validator rewards up to liquidation to the splitter contract. ### Operator Pool (20%) 20% of transaction fees and validator rewards will go to the Node Operator, to be used at their sole discretion and without limitation. No other compensation will be provided for the node operation service. The node operator will provide access to the nodes running canary validators to Hyperledger mainnet developers and all maintainers performing mainnet work for development and debugging purposes. Access to performance nodes may be restricted to node operators, at the node operator's discretion. There is an expectation that if a contributor receives access nodes, they will then be added to the respective monitoring channels for those nodes. ### Hyperledger Pool (20%) HLF will receive 20% of the transaction fees and validator rewards, independent of any maintainer participation, to direct towards Hyperledger Besu mainnet work, paying for items including but not limited to: * Taxes associated with the reception of funds * Gas fees for the deployment of splitter contracts * Services consumed by the Hyperledger Besu project, such as * Continuous Integration * Cloud Hosting fees for development (i.e. testnet nodes) * Source code hosting * Any other such services directly related to development of mainnet capabilities in Hyperledger Besu * *Note*: These costs are separate from any incurred by any other participating organization * Sending maintainers to speak at and promote Hyperledger Besu at Hyperledger events (such as the Global Forum and Members Summit) and Ethereum Foundation events (such as DevCon and research/development workshops) * Posting Bounties for work on Hyperledger Besu mainnet or mainnet related work * Spending that would directly promote interoperability with Besu Mainnet functionality * Other spending that would directly promote and improve Hyperledger Besu's mainnet activities ### Mainnet Maintainer Pool (60%) The remaining 60% of rewards and fees will be split across Mainnet Maintainers (MMs). The Besu community will manage a list of maintainers with substantial contributions to mainnet in a vesting period and fees available in the next period will be split across these MMs. The share of funds for MMs employed by member organizations of HLF will be sent to their member organization by default. That said, MMs do not need to be affiliated with a member organization of HLF to be eligible for this. The only requirement is the MM having made a significant contribution to Besu's Ethereum mainnet support during a vesting period. If there is contention around a maintainer’s contribution to mainnet, that will be escalated to the EF and HLF staff to decide on whether they meet eligibility for this period. The Mainnet Maintainer Pool in Vesting Period `N` is split according to the number of eligible maintainers during Vesting Period `N-1`, not their total contributions during that period, and is reset every vesting period. For example, if during Vesting Period 3, OrgA has 5 eligible maintainers, OrgB has 3 and 2 independent maintainers have also made eligible contributions, in Vesting Period 4, 50% of the maintainer pool fees will be sent to OrgA, 30% to OrgB and 10% to each of the two independent maintainers. These contributions would not be taken into account when distributing fees for subsequent vesting periods. Given that transaction fees will accrue starting at The Merge, contributions between Jan 1, 2022 and The Merge will be considered for the initial split contract. Then, when the first withdrawal key distribution happens (upon activation of Beacon Chain withdrawals), contributions from The Merge to the distribution event will be the ones reflected in the updated weights for the next vesting period. Member organizations and independent maintainers will be asked to provide an address over which they have custody for each period during which they are eligible to receive a share of fees. ## Withdrawal Keys Distribution Access to validator withdrawal keys is reserved to Patron Organizations (POs), who are organizations which employ Patron Maintainers (PMs) and demonstrate long term, significant support towards Besu's mainnet work. ### Patron Eligiblity **To recognize ConsenSys and HLF's historical contributions to Besu, these two organizations will be the only POs in the initial vesting period.** The addition of future PMs & POs will be at the EF's sole discretion. Factors considered for potential PMs & POs include: * Quantity and impact of past contributions to Besu's mainnet support, with an eye towards features (e.g. sync, state management) or EIPs relevant for mainnet network upgrades, as well as other consensus critical changes; * Engagement with other Ethereum mainnet client teams and researchers in public forums and/or in-person events where multiple Ethereum client teams participate, i.e., beyond the Besu community itself; * Proactive efforts around improving the Ethereum mainnet, either through applied R&D, championing EIPs, testing infrastructure, performance optimizations, etc. Organizations need active PMs contributing to Besu's mainnet efforts for at least one vesting period before being eligible to be considered to become a PO. Additionally, they must plan to maintain their contributions for at least one more vesting period, at the end of which they will be eligible for withdrawal key distributions. Maintainers and organizations desiring to become Patrons can reach out to the EF directly. Tim Beiko ([email protected]) is the current best contact for this. ### Distribution The distribution of withdrawal keys is reserved for PMs and POs. If PMs are eligible for a share of keys, but not employed by a PO, their share of keys will be sent to HLF. Similarly to the transaction fee and validator rewards distributions, contributions by PMs in each period will be used to determine the share of withdrawal crendentials sent to each PO. Note: withdrawal keys are sent based on contributions in the **current** period rather than the previous one, as for transaction fees & validator rewards. While the share of keys going to each PO will be calculated based on each periods' contributions, the percentages might not map perfectly to the available number of keys for this period. In this case, the average share of contributions over each period in the program will be considered, and keys will be sent to the PO farthest from their current fair share. The following table illustrates a fictitious example of various organizations's eligible share of contributions over the initial 4 periods of the program, based on mainnet maintainers across each organization. Cells which are highlighted in yellow show periods during which an organization is considered a PO.  Let us unpack this. In Period 1, CS and HLF are the two only POs, and `Org A`, a candidate PO, already has a PM. `Org B`, another candidate PO, does not. At the end of this period, `Org A`'s PM's contributions accrue to HLF. CS and HLF are thus the only POs with eligible contributions. In Period 2, `Org A` is now officially a PO. It now accrues a share of withdrawal credential proportional to its PM's contributions. Because there are no PMs without a tie to a PO, HLF's share for this period is 0. In Period 3, `Org B` now has a PM, but is not officially a PO yet. Therefore, as for `Org A` in Period 1, `Orb B`'s PM's contribution's share accrues to HLF, while CS and `Org A` both get their PM's shares of eligible contributions. Finally, in Period 4, `Org B` is also an official PO. CS, `Org A` and `Org B` each accrue their share of withdrawal credentials based on their PM's contributions. --- Let us add another table illustrating what the withdrawal key distribution would look like in this example:  In each period, we look at each PO's eligible share of contributions, and split the credentials accordingly. When the numbers do not divide evenly based on the number of credentials available in the period, we round in favor of the PO who is furthest from their fair share, meaning the number of keys they would have gotten based on the average of their eligible share of the keys across all periods. Each period, patrons whose current share of keys exceed their share of eligible contributions are marked in green, while patrons whose current share of keys is inferior to their share of eligible contributions are marked in red. For example, in Period 2, `Org A`, who had received 0 keys in Period 1, receives 1 key, or 16.67% of the period's total keys, despite having only 14.29% of eligible contributions. This brings their total share of keys up from 0% to 2.63%, closer to their average share of eligible contributions over the entire program, 7.14% (0% in Period 1 + 14.29% in Period 2, divided across both periods). The same logic is applied in Period 3, where `Org A` receives 30% of keys for 20% of contributions to further reduce its deficit. By the end of Period 4, all POs are within a few percents of their average share of contributions across periods. If, at the end of the program, a large (>5%) discrepancy existed between POs' eligible contributions and their shares of keys, POs can agree to liquidate validators to distribute funds proportionally to contributions. The spreadsheet with the example values is available [here](https://docs.google.com/spreadsheets/d/1BAYv0b83Dj28ujSB_pRSzR5iAc7FRyDJiueG_b09XrY/edit?usp=sharing). ### Liquidation and Impact to Mainnet Maintainer Pool The EF releases the withdrawal keys in the vesting period (as identified in the contract under “Milestones”) in the proportional manner identified above. Once withdrawals are received by a Patron Organization, that PO can choose to liquidate their validators. No PO will have any influence on any other patron's choice to liquidate, regardless of maintainership participation. In practice, this means that POs forfeit the right to determine if and how HLF liquidates validators for which it has withdrawal keys. If a PO chooses to liquidate their validator(s) principal (e.g. the full 32ETH, causing a validator exit, rather than only withdrawing accumulated rewards), that PO will reduce their share of the remaining Mainnet Maintainer Pool in equivalent proportion to the amount of validators they have liquidated. For example, if a PO liquidates 10% of its validators, that organization's share of the Mainnet Maintainer Pool will be reduced by 10% going forward. The extreme version is that an organization who liquidates all its validators it is then ineligible for Mainnet Maintainer Pool funds from the remaining validators. **Additionally, it is expected that a Patron liquidating a validator distributes its associated validator rewards prior to liquidation as per the "Transaction Fees & Validator Rewards Distribution" section above.** The one exception to this is HLF, whose share of the maintainer pool will always be proportional to the number of eligible maintainers not affiliated with any PO, regardless of validator liquidations. While HLF can, at its sole discretion, liquidate validators for which it has withdrawal keys to cover taxes, further liquidations must be agreed to by the Besu community. The specifics of how this is decided are left to the Besu community to determine, and the EF reserves the right to withhold withdrawal credentials until a process which has been agreed to is in place. Reductions to Mainnet Maintainer Pool participation shall have no impact on Operator or Hyperledger Pool distributions, which each will receive 20% of transaction fees and and rewards across the entirerty of remaining validators.