SP1 ZK Oracle is an implementation of LIDO LIP-23 sanity-check oracle, using Succinct SP1. It a separate Oracle that builds a report for each Accounting Oracle reference slot, improving its sanity checks.
The Accounting Oracle is a core component of the Lido protocol that reports the aggregate CL balances of all Lido validators for the daily stETH rebase. Its accuracy is ensured by a 5-of-9 committee of independent Oracle daemons, and the protocol relies on a sanity check to limit potential misreporting.
The current check allows up to a 5% TVL decrease per report. Given a minimum 72-hour governance reaction time, compromised Oracles could reduce reported TVL by 15–20%, triggering liquidations and pushing stETH off-peg. However, real negative rebases have identifiable characteristics that can be leveraged to reduce this attack surface while preserving smooth operation during events like mass slashing.
In case of abnormal negative rebase events, ZK Oracle reports are used to sanity-check Accounting Oracle reports.
Gas estimation
ZK Oracle reports are expected to be processed every day for the Accounting Oracle reference slot. The expected ETH consumption will be around 0.5 ETH per year.
Sorry i’m confused. Just to confirm: this proposal is directed towards the Gas Supply Committee, requesting funding directly from them, and not something that will be voted on?
Yes.
If the Gas Supply Committee determines that funding the ZK Oracle falls within its scope of responsibility, no vote is required. Otherwise, the vote should be started.
Thanks for bringing this proposal forward — it’s encouraging to see Lido engaging more directly with emerging ZK infrastructure rather than treating it as purely external experimentation.
From a strategic standpoint, the idea of a zk oracle that can verifiably attest to off-chain or cross-domain state does seem directionally aligned with where Ethereum is heading, especially as protocols increasingly rely on trust-minimized external inputs. If successful, SP1 could lower verification costs while expanding what is realistically provable on-chain.
That said, I think the key governance question here is less about whether zk oracles are “useful” in the abstract, and more about how critical this specific implementation is to Lido’s medium-term roadmap. For example, are there concrete use cases already identified where SP1 would materially improve Lido’s security model, operational efficiency, or governance guarantees — or is this primarily a strategic option value investment?
I also wonder how the DAO is thinking about dependency risk. Funding infrastructure at this layer can create implicit coupling over time, even without exclusivity. Clear expectations around interoperability, exit options, and long-term maintenance responsibility would help frame this as ecosystem support rather than lock-in.
Overall, I’m open to the proposal, but would appreciate more explicit articulation of success criteria — not just technical milestones, but how the DAO should evaluate whether this funding delivered meaningful protocol-level benefits.
We are actively developing this direction. In the near term, zk oracles are intended to be used as a sanity-check layer for our existing “vanilla” oracles, and this tooling will continue to be expanded over time.
In the long run, our goal is either to replace our current oracles with zk oracles entirely, or to make a zk oracle a member of the oracle quorum, such that a report cannot be finalized without it.
The goal is to make measurable reductions in the level of trust required in privileged participants, which is critical for overall protocol robustness.
The decision to integrate a specific provider into the protocol will be made through a Snapshot vote, currently targeted for Q1 2026. For now, the committee approved funding of 0.1 ETH to cover the costs of testing the SP1 ZK Oracle. A proposal on further funding will be included in the planned Snapshot vote on this matter.