Proposal: Second Opinion ZK Oracle

[VictorP]

Proposal Overview

Lido contributors proposed to improve the safety check for the accounting report in the case of a negative rebase, reducing the possible impact size, but with the requirement for a second opinion for extreme cases. It is described in LIP-23 and was adopted by the DAO in 2024.

This proposal suggests deploying a standalone instance of the Second Opinion ZK Oracle on Ethereum mainnet using Succinct SP1 zkVM technology, initially not connected to the Lido on Ethereum protocol. Integration may be considered after the Fusaka/Glamsterdam hardfork taking into consideration community feedback, accumulated experience, and ongoing protocol development. In the meantime, the oracle’s published reports will serve as an independent, publicly available, and trustlessly posted data feed of Lido-participating validator balances.

The sections below provide details on the ZK Oracle’s functionality and the proposed execution plan.

Motivation

The AccountingOracle contract aggregates all Lido validators’ Beacon Chain balances and Withdrawal Vault balance (clBalanceGwei and withdrawalVaultBalance in the report) to the protocol, critical for the daily rebase of the stETH token. It uses a committee of nine Oracle daemons, with a consensus required from at least five, to ensure data integrity.

The protocol could be harmed if this committee is compromised, malfunctions, or colludes. This risk is acknowledged and constrained by a sanity check that restricts the possible discrepancy in the balance that Oracle can report. The current approach to sanity checking allows the Oracle committee a 0.109 ETH decrease per active validator over an 18-day period (0.101 ETH for attestation penalties and 0.008 ETH for initial slashing penalty). Please note, at the adoption of LIP-23 the sanity checker parameters were at 1.101 ETH, but the parameters were changed later because of the Pectra upgrade. This value, drawn from Ethereum specifications, addresses two out of four cases of ‘Natural CLBalance decrease’ — attestation penalties and the initial slashing penalty. To increase the versatility of the negative rebase check it’s proposed to have a Second Opinion Oracle based on ZK technology, as it was initially proposed in LIP-23.

The Second Opinion ZK Oracle is a safeguard mechanism for the Lido protocol, designed to provide an additional layer of verification for critical balance data. It leverages zero-knowledge technology to independently compute and prove validator balances and withdrawal vault balances. Its primary role is to serve as a “second opinion” to confirm unusually large negative rebases for stETH, thereby reducing the risk of erroneous or malicious oracle reports. The system includes components such as Rust-based programs running inside SP1, a service layer that schedules and executes proofs, Solidity contracts to interface with the protocol, and monitoring endpoints for operational health. The details of the technical design for Second Opinion ZK Oracle can be found here.

Proposed execution plan

1. The second opinion oracle was developed, reviewed internally, and covered by the test suite.

2. It was deployed on Hoodi testnet and has been working since August 2025.

3. The audits were conducted for the pre-Fusaka applicable contract and ZK Program.

4. The ZK Oracle contract will be deployed and verified on mainnet being a standalone (initially not connected to the protocol) public trustless data feed reporting Lido-participating validator balances

5. Drawing on community feedback, accumulated experience, and ongoing protocol development, a governance vote will be initiated to integrate the zkOracle — or its evolved version — into the protocol.

Summary

As a continuation of efforts to enhance the negative rebase sanity checker, the proposal introduces the Second Opinion ZK Oracle. This oracle leverages Succinct Labs’ SP1 technology to provide Zero-Knowledge proofs for the data it supplies, ensuring cryptographic integrity and verifiability. Backed by long-term operation on multiple testnets, an independent audit conducted by Nethermind Security, and independent trustless data feed mode on mainnet, the Second Opinion ZK Oracle aims to provide an additional layer of robustness and security to the Lido on Ethereum protocol.

References

• LIP-23: Negative rebase sanity check with second opinion specification
• Second Opinion ZK Oracle: Technical Design and Architecture
• Github repo
• ZK Lido Oracle powered by Succinct
• Oracle committee 5/9

[cp0x]

Thanks for the interesting proposal

However, what real threats remain uncovered by the system
5/9 Oracle + sanity check?

Can you give specific attack or failure scenarios that cannot be caught using existing mechanisms?

[VictorP]

@cp0x , thank you for highlighting this aspect!

Overall, the 5/9 oracle committee plus sanity checker is an effective system. The second opinion further strengthens it.

Attack vectors to consider:

• Small false negative rebase: Committee collusion could produce a subtle negative rebase that the sanity checker does not reject. Even a modest negative rebase can have cascading effects (e.g., forced position liquidations in landing markets).

• Large or moderate false negative rebase: Committee collusion could produce a rebase large enough to trigger the sanity checker. This would pause the protocol’s reporting pipeline until the DAO resolves it. Where a second opinion exists, the ZK Oracle’s data would be used to confirm the rebase and restore normal operation.

[Lanski]

Wow, had to go back a bit and dig into past threads to figure out what’s going on, so I’ll put down what I had to trace back for others to easily inform themselves for the vote.

LIP 23 was passed June 24 to improve the safety check for the accounting report in the case of a negative rebase. Among the improvements, there was the possibility to consult a secondary Oracle, but none was ready at the time:

@Greg_S

Initially, it is suggested that there should be no secondary opinion source but rather an interface to integrate a preferred provider later on. Once available, the ideal secondary opinion source would be a ZKP-based Oracle, similar to those discussed on the forum (more details on this in references). Alternatively, options might be considered such as a third-party Oracle committee or even a multisig-controlled manual quasi-Oracle.

At the time, 3 implementations were suggested.

1. One approach was deemed too expensive:

[ZKLLVM] Trustless ZK-proof TVL oracle

Hey everyone, sharing a brief update on the state of =nil; Foundation’s zkOracle for Lido. Recently, we came to a crossroads for development. After running some preliminary tests on our first Prover version, we realized we would not be able to meet the desired requirement for Lido for this zkOracle. Specifically, those requirements are: Proof generation time: 30min Proof generation cost: $200 Our initial tests came out to approximately 2 hours for ~$1k. You can see our first update here. Af…

2. another approach hasn’t updated since 2023 (unless I’ve missed another thread):
   DendrETH: A trustless oracle for liquid staking protocols

3. and this one, whose original thread can be found here:
   https://research.lido.fi/t/zk-lido-oracle-powered-by-succinct/

---

I’m very happy that all this is being built openly and we can see the rationale, design process, effects, audits and tests. Honestly amazing work again by the Lido team building in the open and organising other teams to help build critical pieces.

In the LIP-23 definition, the following security consideration is mentioned:
“Considering the current design of the Dual governance, it is possible that the protocol will face a deadlock. If the protocol is in a rage quit state, votes cannot be executed unless all stETH is withdrawn from the rage quit contract. Withdrawal requires an Oracle report, so if something (…) would cause the trigger of the sanity check, the protocol enters a dead-lock situation, where stETH can not be withdrawn due to the lack of Oracle reports, Oracle reports do not pass due to sanity check, and the sanity check cannot be changed since votes are blocked by Dual Governance veto.”

Would the 2nd Opinion Oracle unwind this gridlock described above?

I think you hint at the response to my question here, but I rather ask than assume.

@VictorP

Large or moderate false negative rebase: Committee collusion could produce a rebase large enough to trigger the sanity checker. This would pause the protocol’s reporting pipeline until the DAO resolves it. Where a second opinion exists, the ZK Oracle’s data would be used to confirm the rebase and restore normal operation.

[VictorP]

@Lanski thank you very much for putting the details together! Indeed, it’s a long journey strengthen protocol security one step at a time.

Just one small correction: you mentioned LIP-24, but that looks like a typo — the correct reference is LIP-23. Here is the exact paragraph from the document. That’s accurate, integrating the Second Opinion ZK Oracle into the protocol resolves the gridlock in this scenario.

[Lanski]

yup, typo - editing it!

And thanks for confirming - the gridlock seems hard to reach but I’m very happy to see that this would resolve it

[cp0x]

@[ZKLLVM] Trustless ZK-proof TVL oracle

Specifically, those requirements are:

• Proof generation time: 30min
• Proof generation cost: $200

Do I understand correctly that these requirements are now being met?

[VictorP]

@cp0x That’s a great question, thanks! The progress on proof cost and performance with SP1 has been remarkable. On the Hoodi testnet, each proof costs around $5 and takes about 5–10 minutes to generate. The complexity of the ZK program mainly depends on the size of the validator set, which is comparable between Hoodi and Mainnet. Because of this, we expect similar numbers on Mainnet as well.