Hi everyone,
Wanted to provide a transparent update on the status of the ZK Oracle Second Opinion effort discussed in this thread
Acknowledging the progress
The Boundless team has demonstrated a working implementation that seems to meet most of the original milestones: LIP-23-compliant guest program, on-chain verification via the SecondOpinionOracle interface, Boundless proving integration, and mainnet proofs generated within 30 minutes at ~$5 per report — sits under the original $50 target. The trust and upgrade model (immutable image IDs, freezable oracle contract, RISC Zero verifier router) is sound. We appreciate the work that went into this and want to be clear: the zk technology is not the issue.
Pausing for now
Three developments have converged that make continuing the ZK oracle effort hard to extend right now for Lido contributors:
1. The 0x02 validator consolidation demands full engineering focus
Lido is in the middle of the largest infrastructure migration in the protocol’s history. The Pectra-enabled transition to 0x02 compounding credentials and validator consolidation — shipping as part of Staking Router v3 and Curated Module v2 — touches core protocol accounting, the oracle system, and the security model. The same engineering team, oracle infrastructure, and audit pipeline that would be required to integrate a ZK oracle are fully committed to this migration for the next few months.
Critically, the oracle’s accounting model itself is being rewritten from unit-based (1 validator = 32 ETH) to balance-based accounting. The ZK oracle cannot be finalized until this new architecture stabilizes.
See: Understanding Protocol Costs for 0x02 and the CMv2 Migration and Future of the Curated Module | CMv2 Landscape
Tentatively, the primary Lido protocol testnet deployment on Hoodi is expected to be ready in early May to begin 0x02 test migrations, with the mainnet upgrade planned for sometime in the summer.
2. The Ethereum roadmap signals consensus-layer changes ahead
The Ethereum Foundation’s Strawmap outlines approximately seven hard forks through 2029 on a roughly six-month cadence, many of which touch consensus-layer data structures that ZK programs and circuits directly encode.
ZK oracle programs hardcode the exact Merkle tree layout of BeaconState, Validator, and BeaconBlockBody SSZ containers. Every hard fork that adds or removes fields shifts generalized indices and breaks existing circuits — this has happened at every single fork from Altair through Pectra. The upcoming cadence makes ongoing maintenance of ZK programs and circuits a meaningful recurring cost with each upgrade requiring support (re-development, re-audit, and re-testing).
Looking further ahead, the post-quantum vision includes potential changes to hash functions (SHA-256 → Poseidon), signature schemes (BLS → post-quantum), slot times, and finality mechanisms — any of which might require noticeable rewrites rather than incremental updates.
EIP-7688 (forward-compatible SSZ containers) could help to solve some part of this by ensuring a single breaking change followed by guaranteed forward compatibility. However, its inclusion in Glamsterdam remains not finalized.
3. EIP-4788 anchoring may change under ePBS
EIP-4788 is the critical on-chain anchor for ZK beacon state proofs: the ZK oracle generates a proof against a beacon block root, and the verifier checks it against the root stored in the 4788 ring buffer. Under ePBS (EIP-7732, targeting Glamsterdam), beacon blocks may not always carry execution payloads, meaning some beacon block roots will not be written to the 4788 contract. This breaks the direct anchoring assumption and introduces non-deterministic proof paths with variable gas costs.
See: Beacon Block Root Issue with ePBS
Until the approach is settled, anchoring to the exact reference slots around 4788 (including possible workarounds) carries meaningful rework risk.
What this means
We are suggesting to put this effort on pause until:
- The 0x02 migration is underway and the new oracle accounting model has stabilized
- Glamsterdam ships and the consensus-layer change surface becomes clearer
- The EIP-4788/ePBS anchoring question is resolved
This applies to the initiative broadly — it is not specific to this particular implementation. Even the SP1-based ZK Oracle which started well before, similarly deferred full mainnet integration pending hardfork stabilization.
Looking ahead
We continue to believe that ZK-proven oracle reports are the right long-term direction for protocol security. The question is timing: a ZK oracle solution works best in a relatively stable consensus environment, and Ethereum is underoing a period of a post-quantum readiness structural change. Pushing heavily now for ZK-proven oracle reports means building on shifting foundations and losing a focus on the 0x02-withdrawal credentials protocol stake migration and consolidation.
We’re grateful to the Boundless team for their work and engagement throughout this process, and to the community for the ongoing discussion. We hope to revisit this initiative once the conditions above are met or drastically improve.