|
| 1 | +--- |
| 2 | +title: Pectra MaxEB |
| 3 | +description: Learn more about MaxEB in the Pectra release |
| 4 | +lang: en |
| 5 | +--- |
| 6 | + |
| 7 | +# MaxEB {#maxeb} |
| 8 | + |
| 9 | +*tl;dr:* The Pectra hard fork allows Ethereum validators to opt into a higher max effective balance and compounding by converting from **Type 1** to **Type 2** withdrawal credentials. The official tool to do this is the Launchpad. This operation cannot be reversed. |
| 10 | + |
| 11 | +## Overview {#overview} |
| 12 | + |
| 13 | +### Who is affected? {#who-is-affected} |
| 14 | + |
| 15 | +Anyone who runs a validator - this is likely someone who knows the index (e.g. [Validator #12345](https://beaconcha.in/validator/12345)) of a validator that they control. If you use a protocol to run a validator (e.g. Lido CSM or Rocket Pool), you will have to check with them to see if and when they support maxEB. |
| 16 | + |
| 17 | +If you stake using a liquid staking token (e.g. rETH or stETH), no action is required or recommended. |
| 18 | + |
| 19 | +### What is "maxEB"? {#what-is-maxeb} |
| 20 | + |
| 21 | +maxEB = the MAXimum Effective Balance of a validator. Until the Pectra hard fork, every validator earns on a maximum 32 ETH. After Pectra, validators have the option to earn on any balance between 32 and 2048 ETH, in 1 ETH increments by opting in to the change. |
| 22 | + |
| 23 | +### How does a validator opt in? {#how-does-a-validator-opt-in} |
| 24 | + |
| 25 | +A validator opts into the maxEB change by converting from **Type 1** to **Type 2** withdrawal credentials. This can be done on the [Launchpad](https://launchpad.ethereum.org/) after the Pectra hard fork goes live. As with **Type 0** → **Type 1**, converting from **Type 1** → **Type 2** is an irreversible process. |
| 26 | + |
| 27 | +### What's a withdrawal credential? {#whats-a-withdrawal-credential} |
| 28 | + |
| 29 | +When you run a validator, you have a set of withdrawal credentials. These can be found in your deposit data json or you can view them on your validator's beaconcha.in [deposit tab](https://beaconcha.in/validator/12345#deposits). |
| 30 | + |
| 31 | +1. **Type 0** withdrawal credentials: If your validator's withdrawal credentials begin with `0x00...`, you deposited before the Shapella hard fork and do not yet have a withdrawal address set. |
| 32 | + |
| 33 | + |
| 34 | + |
| 35 | +2. **Type 1** withdrawal credentials: If your validator's withdrawal credentials begin with `0x01...`, you deposited after the Shapella hard fork or already converted your **Type 0** credentials to **Type 1** credentials. |
| 36 | + |
| 37 | +  |
| 38 | + |
| 39 | +3. **Type 2** withdrawal credentials: This new withdrawal credential type will begin with `0x02...` and will be enabled after Pectra. Validators with **Type 2** withdrawal credentials are sometimes called "**compounding validators**" |
| 40 | + |
| 41 | +| **Allowed** | **Not allowed** | |
| 42 | +| --- | --- | |
| 43 | +| ✅ Type 0 → Type 1 | ❌ Type 0 → Type 2 | |
| 44 | +| ✅ Type 1 → Type 2 | ❌ Type 1 → Type 0 | |
| 45 | +| | ❌ Type 2 → Type 1 | |
| 46 | +| | ❌ Type 2 → Type 0 | |
| 47 | + |
| 48 | +### Risks {#risks} |
| 49 | + |
| 50 | +MaxEB enables a validator to send its entire balance to another validator. Users submitting a consolidation request should verify the source and contents of the transaction they're signing. The official tool for taking advantage of maxEB features is the Launchpad. If you do decide to use a third-party tool, you should verify that: |
| 51 | + |
| 52 | +- The source validator's pubkey and withdrawal address match the validator they control |
| 53 | +- The target validator's pubkey is correct and belongs to them |
| 54 | +- The request is a conversion, not a consolidation, if they don't intend to send funds to another validator |
| 55 | +- The transaction is being signed by the correct withdrawal address |
| 56 | + |
| 57 | +We **strongly recommend** discussing any third-party tool you plan to use with the [EthStaker community](https://ethstaker.org/about). It's a helpful place to sanity-check your approach and avoid mistakes. If you use a malicious or misconfigured tool, **your entire validator balance could be sent to a validator you don't control** — with no way to get it back. |
| 58 | + |
| 59 | +## Technical details {#technical-details} |
| 60 | + |
| 61 | +### The flow {#the-flow} |
| 62 | + |
| 63 | +There will be two uses of the `ConsolidationRequest` operation: |
| 64 | + |
| 65 | +1. Converting an existing validator from a **Type 1** to a **Type 2** validator |
| 66 | +2. Consolidating other validators into an existing **Type 2** validator |
| 67 | + |
| 68 | +In a conversion of a **Type 1** to a **Type 2** validator, both the *source* and *target* will be the validator you are converting. The operation will cost gas and will be queued behind other consolidation requests. This queue is **separate** from the deposit queue and is unaffected by new validator deposits and can be viewed on [pectrified.com](https://pectrified.com/). |
| 69 | + |
| 70 | +To consolidate validators, you must have a *target validator* that has a **Type 2** withdrawal credential. This is the destination of any validator balances being consolidated, and the index being preserved. |
| 71 | + |
| 72 | +### Requirements for converting to Type 2 {#requirements-for-converting-to-type-2} |
| 73 | + |
| 74 | +This will be required for the first validator you convert to **Type 2**. This validator's index is preserved and active. For a conversion, the *source validator* == the *target validator.* |
| 75 | + |
| 76 | +The validator must... |
| 77 | + |
| 78 | +- be active |
| 79 | +- have **Type 1** withdrawal credentials |
| 80 | +- not be in an exiting state (or slashed) |
| 81 | +- not have pending manually-triggered withdrawals (does not apply to sweeps) |
| 82 | + |
| 83 | + |
| 84 | + |
| 85 | +### Requirements for consolidating {#requirements-for-consolidating} |
| 86 | + |
| 87 | +This is the *same operation* as converting but is when the *source validator* is different from the *target validator*. The target validator's index is preserved and accepts the balance from the source validator. The source validator's index is put into an `EXITED` state. |
| 88 | + |
| 89 | +In this case, the source validator has all the same requirements as above plus: |
| 90 | + |
| 91 | +- has been active for at least ~27.3 hours (one `SHARD_COMMITTEE_PERIOD`) |
| 92 | + |
| 93 | +The target validator must |
| 94 | + |
| 95 | +- have **Type 2** withdrawal credentials |
| 96 | +- not be in an exiting state. |
| 97 | + |
| 98 | + |
| 99 | + |
| 100 | +### The consolidation request {#the-consolidation-request} |
| 101 | + |
| 102 | +The consolidation request will be signed by the withdrawal address associated with the source validator and have: |
| 103 | + |
| 104 | +1. Address of the source validator (e.g. `0x15F4B914A0cCd14333D850ff311d6DafbFbAa32b`) |
| 105 | +2. Public key of the source validator (e.g. `0xa1d1ad0714035353258038e964ae9675dc0252ee22cea896825c01458e1807bfad2f9969338798548d9858a571f7425c`) |
| 106 | +3. Public key of that target validator |
| 107 | + |
| 108 | +In a conversion, 2 & 3 will be the same. This operation can be done on [the Launchpad](https://launchpad.ethereum.org/). |
| 109 | + |
| 110 | +### Signing requirements {#signing-requirements} |
| 111 | + |
| 112 | +To submit a `ConsolidationRequest`, the **withdrawal address of the source validator** must sign the request. This proves control over the validator funds. |
| 113 | + |
| 114 | +### What is signed? {#what-is-signed} |
| 115 | + |
| 116 | +A domain-separated [signing root](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#compute_signing_root) of the `ConsolidationRequest` object is used. |
| 117 | + |
| 118 | +- **Domain:** `DOMAIN_CONSOLIDATION_REQUEST` |
| 119 | +- **Signing root fields:** |
| 120 | + - `source_pubkey`: `BLSPubkey` |
| 121 | + - `target_pubkey`: `BLSPubkey` |
| 122 | + - `source_address`: `ExecutionAddress` |
| 123 | + |
| 124 | +The resulting **BLS signature** is submitted alongside the request. |
| 125 | + |
| 126 | +Note: The signing is done by the withdrawal address, not the validator key. |
| 127 | + |
| 128 | +### Partial withdrawals {#partial-withdrawals} |
| 129 | + |
| 130 | +Validators with **Type 1** credentials get automatic, gasless sweeps of their excess balance (anything over 32 ETH) to their withdrawal address. Because **Type 2** allows a validator to compound balances in 1 ETH increments, it will not automatically sweep balances until it reaches 2048 ETH. Partial withdrawals on **Type 2** validators must be manually triggered and will cost gas. |
| 131 | + |
| 132 | +## FAQ {#FAQ} |
| 133 | + |
| 134 | +### **Does opting-in change my proposal luck or rewards?** |
| 135 | + |
| 136 | +No. Opting in does not decrease your change of proposal - your duties and proposal selection remain the same. For example, if you have two 32 ETH validators vs one 64 ETH validator, you will have the same total chances of being selected to propose a block and earn rewards. |
| 137 | + |
| 138 | +### **Does opting in change my slashing risk?** |
| 139 | + |
| 140 | +For smaller or unprofessional operators, the short answer is no. The longer answer is that, for professional operators running many validators per node with fast alerting, consolidating into fewer validators may reduce their ability to react to a slashing and prevent cascade events. The initial slashing *penalty* for all validators has been dramatically reduced from 1 ETH (per 32 ETH) to 0.0078125 ETH (per 32 ETH) to offset this risk. |
| 141 | + |
| 142 | +### **Do I have to exit my validator to convert?** |
| 143 | + |
| 144 | +No. You can convert in place without exiting. |
| 145 | + |
| 146 | +### How long will it take to convert / consolidate? |
| 147 | + |
| 148 | +A minimum of 27.3 hours but consolidations are also subject to a queue. This queue is independent of the deposit and withdrawal queues and is not affected by them. |
| 149 | + |
| 150 | +### Can I keep my validator index? |
| 151 | + |
| 152 | +Yes. In-place conversion keeps the same validator index. If you consolidate multiple validators, you'll only be able to keep the index of the *target validator*. |
| 153 | + |
| 154 | +### Will I miss attestations? |
| 155 | + |
| 156 | +During a consolidation into another validator, the source validator is exited and there is a ~27 hour waiting period before the balance is active on the target validator. This period **does not affect performance metrics**. |
| 157 | + |
| 158 | +### Will I incur penalties? |
| 159 | + |
| 160 | +No. As long as your validator is online, you will not incur penalties. |
| 161 | + |
| 162 | +### Do the withdrawal addresses of the validators being consolidated have to match? |
| 163 | + |
| 164 | +No. But the *source* must authorize the request from its own address. |
| 165 | + |
| 166 | +### Will my rewards compound after converting? |
| 167 | + |
| 168 | +Yes. With **Type 2** credentials, rewards above 32 ETH are automatically restaked — but not instantly. Because of a small buffer (called [*hysteresis*](https://eth2book.info/capella/part2/incentives/balances/#hysteresis)), your balance needs to reach **about 1.25 ETH more** before the extra is restaked. So instead of compounding at 33.0 ETH, it happens at 33.25 (effective balance = 33 ETH), then 34.25 (effective balance = 34 ETH), and so on. |
| 169 | + |
| 170 | +### Can I still get automatic sweeps after converting? |
| 171 | + |
| 172 | +Automatic sweeps will only happen with excess balances over 2048. For all other partial withdrawals, you'll need to manually trigger them. |
| 173 | + |
| 174 | +### Can I change my mind and go back from Type 2 to Type 1? |
| 175 | + |
| 176 | +No. Converting to **Type 2** is irreversible. |
| 177 | + |
| 178 | +### My validator is offline or below 32 ETH - can I still convert it? |
| 179 | + |
| 180 | +Yes. As long as it's active (not exited) and you can sign with its withdrawal address, you can convert it. |
| 181 | + |
| 182 | +## Resources {#resources} |
| 183 | + |
| 184 | +- [Electra consensus specs](https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/beacon-chain.md): This is the ‘truest' version that you should rely on. When in doubt, read the specs |
| 185 | +- Not everybody is comfortable wading through code, so [this maxEB-GPT](https://chatgpt.com/g/g-67f1650fb48081918f555e0c8d1c2ae9-maxeb-gpt) can help interpret the specs. *Disclaimer: The specs, not the AI, should be relied on as truth, as the AI may misinterpret information or hallucinate answers* |
| 186 | +- [pectrified.com](https://pectrified.com/): View the state of consolidations, deposits, and queue waiting times |
| 187 | +- [Ethereal](https://github.com/wealdtech/ethereal): Community-created CLI tool for managing common validator tasks |
| 188 | +- [batch-validator-depositor](https://github.com/attestantio/batch-validator-depositor): Community-created contract that allows multiple Ethereum validators to be deposited in a single transaction |
0 commit comments