# LIP 27: Ensuring Compatibility with Ethereum’s Pectra Upgrade
**URL:** https://research.lido.fi/t/lip-27-ensuring-compatibility-with-ethereum-s-pectra-upgrade/9444
**Category:** Proposals
**Created:** [January 30, 2025, 12:31pm UTC](https://research.lido.fi/t/lip-27-ensuring-compatibility-with-ethereum-s-pectra-upgrade/9444 "2025-01-30T12:31:33Z")
**Posts on this page:** 15
**Page:** 1
### Author:  [@Maksim\_Kuraian](https://research.lido.fi/u/Maksim_Kuraian)
#### Post date: [January 30, 2025, 12:31pm UTC](https://research.lido.fi/t/lip-27-ensuring-compatibility-with-ethereum-s-pectra-upgrade/9444/1 "2025-01-30T12:31:33Z")
# Ensuring Compatibility with Ethereum’s Pectra Upgrade
This post outlines the technical details of the proposed upgrade to the Lido protocol to ensure continuous operation with Ethereum’s upcoming Pectra hardfork. The focus is exclusively on compatibility, rather than integrating any new features introduced by Pectra. Pectra-related new functionalities, such as Triggerable Withdrawals via [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) and increasing the `MAX_EFFECTIVE_BALANCE` & validator consolidations via [EIP-7251](https://eips.ethereum.org/EIPS/eip-7251), will be addressed in separate posts.
Following the forum discussion, this proposal will be presented on Snapshot to seek DAO support for preparing Lido on Ethereum for the Pectra upgrade. If the proposal is supported, two on-chain votes will follow: one before and one after the Pectra hardfork.
The proposal’s technical scope consists of three parts:
1. Deployment of a new version of CS Verifier Contract;
2. Items for the further on-chain vote **before** the hardfork;
3. Items for the further on-chain vote **after** the hardfork.
The on-chain vote **before** the hardfork includes only the minimal changes necessary to keep the Lido protocol functioning correctly after the Pectra upgrade. The on-chain vote **after** the hardfork includes optimizations that have no strict timeline and can be implemented without a set deadline post-upgrade.
The following sections outline how updates to Lido’s **Oracles** , **Oracle Report Sanity Checker** , and **CS Verifier** contracts are proposed. Details of the upcoming Pectra upgrade, its impact on the Lido protocol, and recommended protocol changes can be found in [LIP-27: Ensuring Compatibility with Ethereum’s Pectra Upgrade](https://github.com/lidofinance/lido-improvement-proposals/blob/develop/LIPS/lip-27.md).
Valset technical contributors are available to address any questions that may arise.
* * *
## Part 1. Deployment
### CS Verifier Contract
#### Remove Initial Slashing Penalty Report
Under Pectra, the penalty for newly slashed validators is roughly 0.0078 ETH for a 32 ETH validator, rather than ~1 ETH.
Therefore, it’s proposed to remove the initial slashing penalty report from the CS Verifier contract before the Pectra hardfork activation. Accounting of losses for initial slashing will take place at the moment of reporting the full withdrawal of the validator.
#### Update gIndexes
It is proposed to redeploy the contract with two sets of gIndexes: one for the current (Deneb) fork version and one for the Electra fork version, along with a specific slot number for the hardfork activation.
```solidity
// gIndexes calculation:
// https://github.com/lidofinance/community-staking-module/blob/4d5f4700e356dc502c484456fbf924cba56206ad/script/gindex.mjs#L36
GI_FIRST_WITHDRAWAL_PREV = 0x0000000000000000000000000000000000000000000000000000000000e1c004;
GI_FIRST_WITHDRAWAL_CURR = 0x000000000000000000000000000000000000000000000000000000000161c004;
GI_FIRST_VALIDATOR_PREV = 0x0000000000000000000000000000000000000000000000000056000000000028;
GI_FIRST_VALIDATOR_CURR = 0x0000000000000000000000000000000000000000000000000096000000000028;
GI_HISTORICAL_SUMMARIES_PREV = 0x0000000000000000000000000000000000000000000000000000000000003b00;
GI_HISTORICAL_SUMMARIES_CURR = 0x0000000000000000000000000000000000000000000000000000000000005b00;
// The first slot of the Deneb activation epoch https://eips.ethereum.org/EIPS/eip-7569#activation
FIRST_SUPPORTED_SLOT = 8626176;
// TBA after the Pectra activation epoch for mainnet is known
// first slot of the Electra activation epoch
PIVOT_SLOT =
```
## Part 2. Vote before the Pectra hardfork
### Oracles consensus version
It is proposed to increment the consensus version for Accounting, Validator Exit Bus, and CSM oracles.
- [Accounting Oracle `0x852deD011285fe67063a08005c71a85690503Cee`](https://etherscan.io/address/0x852deD011285fe67063a08005c71a85690503Cee#readProxyContract#F16): from `2` to `3`
- [Validator Exit Bus Oracle `0x0De4Ea0184c2ad0BacA7183356Aea5B8d5Bf5c6e`](https://etherscan.io/address/0x0De4Ea0184c2ad0BacA7183356Aea5B8d5Bf5c6e#readProxyContract#F13) from `2` to `3`
- [CSM Fee Oracle `0x4D4074628678Bd302921c20573EEa1ed38DdF7FB`](https://etherscan.io/address/0x4D4074628678Bd302921c20573EEa1ed38DdF7FB#readProxyContract#F16) from `1` to `2`
The new consensus version will signal the oracles to switch to the new algorithm that considers the transition through Pectra: before the hardfork, the algorithm collects the report in the old way, after the hardfork, in the new way.
### Update CS Verifier Contract
It is proposed to revoke the verifier role on the Community Staking Module contract from the old CS Verifier contract and grant it to the new CS Verifier contract, which will be deployed in advance (as described in the “Deployment” section above).
This update involves two steps:
1. **Revoke** the [VERIFIER\_ROLE (`0x0ce23c3e399818cfee81a7ab0880f714e53d7672b08df0fa62f2843416e1ea09`)](https://etherscan.io/address/0xdA7dE2ECdDfccC6c3AF10108Db212ACBBf9EA83F#readProxyContract#F16) on the [Community Staking Module (`0xdA7dE2ECdDfccC6c3AF10108Db212ACBBf9EA83F`)](https://etherscan.io/address/0xdA7dE2ECdDfccC6c3AF10108Db212ACBBf9EA83F) contract from the old [CS Verifier (`0x3Dfc50f22aCA652a0a6F28a0F892ab62074b5583`)](https://etherscan.io/address/0x3Dfc50f22aCA652a0a6F28a0F892ab62074b5583) contract.
2. **Grant** the [VERIFIER\_ROLE (`0x0ce23c3e399818cfee81a7ab0880f714e53d7672b08df0fa62f2843416e1ea09`)](https://etherscan.io/address/0xdA7dE2ECdDfccC6c3AF10108Db212ACBBf9EA83F#readProxyContract#F16) on the [Community Staking Module (`0xdA7dE2ECdDfccC6c3AF10108Db212ACBBf9EA83F`)](https://etherscan.io/address/0xdA7dE2ECdDfccC6c3AF10108Db212ACBBf9EA83F) contract to the new CS Verifier contract. The address of the new CS Verifier will be posted in this thread after deployment.
## Part 3. Vote after the Pectra hardfork
### Sanity Checker
It is proposed to update the following parameters in the Oracle Report Sanity Checker contract [`0x6232397ebac4f5772e53285b26c47914e9461e75`](https://etherscan.io/address/0x6232397ebac4f5772e53285b26c47914e9461e75):
- `exitedValidatorsPerDayLimit`: from `9000` to `3600`;
- `appearedValidatorsPerDayLimit`: from `43200` to `1800`;
- `initialSlashingAmountPWe`: from `1000` to `8`.
#### exitedValidatorsPerDayLimit = `3600`
This parameter defines the maximum number of validators that may be reported as “exited” per day, depending on the consensus layer churn limit.
In Pectra, a limit `MAX_PER_EPOCH_ACTIVATION_EXIT_CHURN_LIMIT` is introduced on the amount of ETH that can be exited per epoch. Therefore, the maximum number of validators that can exit the network per day can be simplified and calculated as:
```python
# https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#time-parameters
SLOTS_PER_EPOCH = 32
# https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#time-parameters-1
SECONDS_PER_SLOT = 12
# https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#validator-cycle
EJECTION_BALANCE = 16 * 10 ** 9
# https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/beacon-chain.md#validator-cycle
MAX_PER_EPOCH_ACTIVATION_EXIT_CHURN_LIMIT = 256 * 10 ** 9
epochs_per_day = 24 * 60 * 60 / SECONDS_PER_SLOT / SLOTS_PER_EPOCH = 225
exited_validators_per_epoch_limit = MAX_PER_EPOCH_ACTIVATION_EXIT_CHURN_LIMIT / EJECTION_BALANCE = 16
exited_validators_per_day_limit = exited_validators_per_epoch_limit * epochs_per_day = 3600
```
#### appearedValidatorsPerDayLimit = `1800`
This parameter defines the maximum number of validators that can be reported as “appeared” in a single day, limited by the maximum daily deposits via the [Deposit Security Module](https://docs.lido.fi/guides/deposit-security-manual).
In Pectra, validators are added to the registry after their deposit passes through the `pending_deposits` queue, which is limited by the [`MAX_PER_EPOCH_ACTIVATION_EXIT_CHURN_LIMIT`](https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/beacon-chain.md#validator-cycle). Given that Lido validators are deposited exclusively with 32 ETH each, the maximum number of Lido validators that can appear on the network per day can be calculated as:
```python
# https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#time-parameters
SLOTS_PER_EPOCH = 32
# https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#time-parameters-1
SECONDS_PER_SLOT = 12
# https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#validator-cycle
EJECTION_BALANCE = 16 * 10 ** 9
# https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/beacon-chain.md#validator-cycle
MAX_PER_EPOCH_ACTIVATION_EXIT_CHURN_LIMIT = 256 * 10 ** 9
# https://github.com/lidofinance/core/blob/901c0e19b752f5ea03118d71881d8b72ccee44c0/contracts/0.8.9/BeaconChainDepositor.sol#L23
DEPOSIT_SIZE = 32 * 10 ** 9
epochs_per_day = 24 * 60 * 60 / SECONDS_PER_SLOT / SLOTS_PER_EPOCH = 225
appeared_validators_per_epoch_limit = MAX_PER_EPOCH_ACTIVATION_EXIT_CHURN_LIMIT / DEPOSIT_SIZE = 8
appeared_validators_per_day_limit = appeared_validators_per_epoch_limit * epochs_per_day = 1800
```
#### initialSlashingAmountPWei = `8` (0.008 ETH)
This parameter defines the maximum initial slashing penalty for validators in the case of misbehavior. It ensures that a slashed validator can be penalized up to 0.008 ETH, contributing to the overall negative rebase calculation during the sanity check process.
In Pectra, `MIN_SLASHING_PENALTY_QUOTIENT_ELECTRA` increases by 128 times from `32` to `4096`, reducing the initial penalty size by 128 times. Since Lido validators exclusively use the [`ETH1_ADDRESS_WITHDRAWAL_PREFIX`](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/validator.md#eth1_address_withdrawal_prefix), their effective balance [is limited to `MIN_ACTIVATION_BALANCE`](https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/beacon-chain.md#new-get_max_effective_balance). Therefore, the maximum initial slashing penalty is calculated as:
```python
# https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/beacon-chain.md#gwei-values
MIN_ACTIVATION_BALANCE = 32 * 10 ** 9
# https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/beacon-chain.md#rewards-and-penalties
MIN_SLASHING_PENALTY_QUOTIENT_ELECTRA = 4096
initial_slashing_amount_gwei = MIN_ACTIVATION_BALANCE / MIN_SLASHING_PENALTY_QUOTIENT_ELECTRA = 0.0078125
initial_slashing_amount_pwei = initial_slashing_amount * 10 ** 3 = 7.8125 # ~8
```
## Fallback Plan
If any risks related to the on-chain voting before the Pectra upgrade are identified, or if the DAO does not approve the proposed update, the fallback plan will be implemented.
One day before the Pectra upgrade, deposits will be paused, and the unpause of deposits will be put to a separate vote for the DAO to decide after Pectra. This measure is necessary to ensure the stable operation of the Lido protocol.
This scenario is unlikely, but if it materializes, a detailed action plan will be outlined separately on the forum.
## Coming Soon: Deployed Contracts and Audit Verifications
After the deployment, addresses for the newly deployed contracts will be provided. These contracts will undergo verification by external auditors, audit reports will be released, detailing the findings and mitigations before the on-chain votes.
Additionally, descriptions of the items up for vote will be published, offering the community a clearer understanding of the proposed changes and their implications for the protocol.
---
### Author:  [@Mol\_Eliza](https://research.lido.fi/u/Mol_Eliza)
#### Post date: [February 4, 2025, 11:22am UTC](https://research.lido.fi/t/lip-27-ensuring-compatibility-with-ethereum-s-pectra-upgrade/9444/2 "2025-02-04T11:22:05Z")
Hey there, as a contributor from analytical workstream I highly support this well-thought, and **required** LIP.
It covers all the possible effects outlined in [Research on Pectra effects on the protocol params](https://docs.google.com/document/d/1gRXxYHHG9dmmwiVyM8EC6ZrbK6yzervgzf3cH2zilig/edit?usp=sharing) , with the scope on:
- Module shares and corresponding risk structure
- Oracle report sanity checker params
- Calculations within VEBO and supportive documents
- “Bunker mode” activation triggers and possible parameters changes
As an additional main outlines of research, Pectra upgrade would lead to **lowering** possible consequences of slashing risk for any reasonable scenarios, opening up more protocol design options, while lowering overall risk, simultaneously leading to even lower probability of conditions triggering “Bunker mode”.
---
### Author:  [@Izzy](https://research.lido.fi/u/Izzy)
#### Post date: [February 4, 2025, 2:14pm UTC](https://research.lido.fi/t/lip-27-ensuring-compatibility-with-ethereum-s-pectra-upgrade/9444/3 "2025-02-04T14:14:48Z")
Thank you Maksim and rest of contributors that worked on this LIP. It’s clear that you’ve put a lot of thought into understanding the effects of the Pectra hardfork and relevant EIPs on the overall staking mechanisms of the network as well as their effects on the workings of the Lido protocol (both on and offchain).
I understand that there is quite a bit complexity and work to be done here just to make sure the protocol is in good order once the HF rolls out! That said, I’m also eager to see what ideas and improvements can be suggested for future LIPs in order to integrate upcoming Pectra functionality like Triggerable Withdrawals and increases to MAX\_EB into the Lido protocol, and look forward to more info on this in the coming months.
---
### Author:  [@firstset](https://research.lido.fi/u/firstset)
#### Post date: [February 7, 2025, 11:12am UTC](https://research.lido.fi/t/lip-27-ensuring-compatibility-with-ethereum-s-pectra-upgrade/9444/4 "2025-02-07T11:12:44Z")
> [@Maksim\_Kuraian](#):
>
> Under Pectra, the penalty for newly slashed validators is roughly 0.0078 ETH for a 32 ETH validator, rather than ~1 ETH.
Thanks for the detailed proposal. To confirm, does this mean the initial slashing penalty for a CSM validator will correspondingly be reduced?
---
### Author:  [@Izzy](https://research.lido.fi/u/Izzy)
#### Post date: [February 7, 2025, 2:59pm UTC](https://research.lido.fi/t/lip-27-ensuring-compatibility-with-ethereum-s-pectra-upgrade/9444/5 "2025-02-07T14:59:35Z")
Yes, see [lido-improvement-proposals/LIPS/lip-27.md at develop · lidofinance/lido-improvement-proposals · GitHub](https://github.com/lidofinance/lido-improvement-proposals/blob/develop/LIPS/lip-27.md#3-updates-to-cs-verifier-contract)
---
### Author:  [@Lanski](https://research.lido.fi/u/Lanski)
#### Post date: [March 1, 2025, 9:26pm UTC](https://research.lido.fi/t/lip-27-ensuring-compatibility-with-ethereum-s-pectra-upgrade/9444/6 "2025-03-01T21:26:17Z")
Thank you for such a detailed explanation!
Given the criticality of the upgrade, I would like to request a verification guide for the on-chain actions when the time comes (CC. @kadmil @Olga_K 🙏 🙏 )
---
### Author:  [@governance-data-bot](https://research.lido.fi/u/governance-data-bot)
#### Post date: [March 17, 2025, 3:55pm UTC](https://research.lido.fi/t/lip-27-ensuring-compatibility-with-ethereum-s-pectra-upgrade/9444/7 "2025-03-17T15:55:54Z")
## Snapshot vote started
We’re starting the [Ensuring Compatibility with Ethereum’s Pectra Upgrade](https://snapshot.box/#/s:lido-snapshot.eth/proposal/0xb6559f0cdb1164ae5d63769827c4a275805bd944392a17b60cf51ddc54429dc6) Snapshot, active till Mon, 24 Mar 2025 16:00:00 GMT . Please don’t forget to cast your vote!
---
### Author:  [@Kate\_Alekseeva](https://research.lido.fi/u/Kate_Alekseeva)
#### Post date: [March 24, 2025, 6:47pm UTC](https://research.lido.fi/t/lip-27-ensuring-compatibility-with-ethereum-s-pectra-upgrade/9444/8 "2025-03-24T18:47:02Z")
## Snapshot vote ended
The [Ensuring Compatibility with Ethereum’s Pectra Upgrade](https://snapshot.box/#/s:lido-snapshot.eth/proposal/0xb6559f0cdb1164ae5d63769827c4a275805bd944392a17b60cf51ddc54429dc6) Snapshot has reached a quorum and completed!
The results are:
**For** : 63.3M LDO
**Against** : 16.315 LDO
---
### Author:  [@George](https://research.lido.fi/u/George)
#### Post date: [April 10, 2025, 8:30am UTC](https://research.lido.fi/t/lip-27-ensuring-compatibility-with-ethereum-s-pectra-upgrade/9444/9 "2025-04-10T08:30:56Z")
Hi everyone! I’m happy to announce that the audits of the protocol changes following LIP-27 have been completed, and the affected contract has been deployed and verified by external teams.
### On-chain audits and deployment
The code for the CS Verifier contract was updated according to LIP-27 and deployed at: [0x0c345dfa318f9f4977cdd4f33d80f9d0ffa38e8b](https://etherscan.io/address/0x0c345dfa318f9f4977cdd4f33d80f9d0ffa38e8b). Changes in the contract code were audited by teams that had previously audited the Community Staking Module codebase, of which it is a part. Additionally, teams performed a deployment verification of the contract. The corresponding updates have been applied to the reports. Updated versions of the reports can be found at the following links:
- [Ackee Blockchain Audit of Community Staking Module (LIP-26, LIP-27)](https://github.com/lidofinance/audits/blob/main/Ackee%20Blockchain%20Lido%20Community%20Staking%20Module%20Report%2004-25.pdf)
- [MixBytes On-chain Audit of Community Staking Module (LIP-23, LIP-25, LIP-26, LIP-27)](https://github.com/lidofinance/audits/blob/main/MixBytes%20Lido%20CSM%20Security%20Audit%20Report%2004-25.pdf)
### Off-chain audits
The code of the off-chain oracle was modified according to LIP-27 and audited by two external teams. You can find the reports at the following links:
- [MixBytes Off-chain Audit of Lido Oracle v5](https://github.com/lidofinance/audits/blob/main/MixBytes%20Lido%20Oracle%20v5%2004-25.pdf)
- [Composable Security Off-chain Audit of Lido Oracle v5](https://github.com/lidofinance/audits/blob/main/Composable%20Security%20Lido%20Oracle%20v5%2004-25.pdf)
---
### Author:  [@Kate\_Alekseeva](https://research.lido.fi/u/Kate_Alekseeva)
#### Post date: [April 23, 2025, 2:28pm UTC](https://research.lido.fi/t/lip-27-ensuring-compatibility-with-ethereum-s-pectra-upgrade/9444/10 "2025-04-23T14:28:39Z")
🚀 **Voting Has Started!**
We’re excited to share that [Vote #185](https://vote.lido.fi/vote/185) is now live!
This vote proposes Lido protocol upgrade to ensure continued compatibility with Ethereum’s upcoming Pectra hardfork. The upgrade is strictly focused on maintaining protocol operability and does not introduce any of the new features proposed in Pectra.
🔧 **What’s Being Upgraded?**
The voting script includes 11 steps:
- steps 1–9 update the oracles - [AccountingOracle](https://etherscan.io/address/0x852deD011285fe67063a08005c71a85690503Cee), [ValidatorsExitBusOracle](https://etherscan.io/address/0x0De4Ea0184c2ad0BacA7183356Aea5B8d5Bf5c6e), and [CSFeeOracle](https://etherscan.io/address/0x4d4074628678bd302921c20573eea1ed38ddf7fb) - switching them to a new consensus algorithm designed to ensure correct behavior both before and after the Pectra hardfork;
- steps 10–11 replace the [CS Verifier contract](https://etherscan.io/address/0x3Dfc50f22aCA652a0a6F28a0F892ab62074b5583), removing slashing reports and updating the gIndex structure.
📅 **Deadline**
The vote is open until the end of the main phase: **Apr 26, 14:17 UTC**.
🗳 **How to Participate**
- Review vote items and follow [this guide](https://hackmd.io/@lido/BJn9b91Jgl) for instructions on verifying them.
- Cast your vote before the deadline.
---
### Author:  [@Kate\_Alekseeva](https://research.lido.fi/u/Kate_Alekseeva)
#### Post date: [April 28, 2025, 3:52pm UTC](https://research.lido.fi/t/lip-27-ensuring-compatibility-with-ethereum-s-pectra-upgrade/9444/11 "2025-04-28T15:52:16Z")
**The Vote #185 has been successfully [enacted](https://etherscan.io/tx/0x739b123af3fff812878c56b0fd939569cb16507bfc8678d5225ebd6939331598)!**
Thank you to everyone who participated in the vote! ❤
**Results:**
• **Yes:** 55098227.4 (5.50%)
• **No:** 1 (0.01%)
This vote was a necessary step to ensure continued compatibility with Ethereum’s Pectra upgrade.
We sincerely appreciate your support in making this important upgrade possible! 💕
---
### Author:  [@Kate\_Alekseeva](https://research.lido.fi/u/Kate_Alekseeva)
#### Post date: [May 21, 2025, 8:00pm UTC](https://research.lido.fi/t/lip-27-ensuring-compatibility-with-ethereum-s-pectra-upgrade/9444/12 "2025-05-21T20:00:55Z")
🏁 **[Vote #187](https://vote.lido.fi/vote/187) is now live — make sure to review and vote!**
This vote contains separate updates approved by Lido DAO via Snapshot voting, including a **Post-Pectra update** to adjust Oracle Report Sanity Checker parameters in line with the reduced slashing penalty and updated validator churn limits (items 1-9).
📅 **Deadline**
The vote is open until the end of the main phase: **May 24, 14:17 UTC**.
🔎 **Want to verify vote items?**
Follow this [guide](https://enchanted-direction-844.notion.site/How-to-check-the-Lido-DAO-onchain-vote-187-1f9bf633d0c9806e903ddd64bd625c2b) to check the execution steps and calldata.
---
### Author:  [@Kate\_Alekseeva](https://research.lido.fi/u/Kate_Alekseeva)
#### Post date: [May 26, 2025, 8:48am UTC](https://research.lido.fi/t/lip-27-ensuring-compatibility-with-ethereum-s-pectra-upgrade/9444/13 "2025-05-26T08:48:32Z")
💡 **[Vote #187](https://vote.lido.fi/vote/187)** did not reach quorum and will be rescheduled for **May 27**.
Please stay tuned for the new vote and make sure to participate once it goes live.
---
### Author:  [@Kate\_Alekseeva](https://research.lido.fi/u/Kate_Alekseeva)
#### Post date: [May 27, 2025, 10:30am UTC](https://research.lido.fi/t/lip-27-ensuring-compatibility-with-ethereum-s-pectra-upgrade/9444/14 "2025-05-27T10:30:05Z")
🏁 **[Vote #188](https://vote.lido.fi/vote/188) has just started!**
This is a rerun of [Vote #187](https://vote.lido.fi/vote/187), featuring the same set of proposals.
⏰ Voting is open until the end of the main phase: **May 30, 09:00 UTC.**
Follow [this guide](https://enchanted-direction-844.notion.site/How-to-check-the-Lido-DAO-onchain-vote-188-200bf633d0c9805e81d0deb02fb37a4c) for instructions on reviewing and verifying vote items.
Your voice matters! 💕
---
### Author:  [@nikita.p](https://research.lido.fi/u/nikita.p)
#### Post date: [June 1, 2025, 11:30am UTC](https://research.lido.fi/t/lip-27-ensuring-compatibility-with-ethereum-s-pectra-upgrade/9444/15 "2025-06-01T11:30:14Z")
**[Vote #188](https://vote.lido.fi/vote/188): Passed and Enacted! 🚀**
Thanks to everyone who took part in the voting process.
**Results:**
✔ Yes - 51315931.2 (5.13%)
❌ No - 5.1 (0.01%)
We’re grateful for your trust and continued support! 💛