[Pre-Proposal] Establishing a Post-Quantum Readiness Working Group for Lido Validator Infrastructure

General
1

The Ethereum Foundation has established a dedicated post-quantum research team, and the Strawmap/Lean roadmap targets hash-based signatures across the protocol stack. As the largest single manager of validator signing keys on Ethereum (~9M ETH), Lido’s exposure to quantum-vulnerable BLS keys is proportionally the largest in the ecosystem. This pre-proposal suggests forming a small working group to (1) inventory Lido’s key-management exposure, (2) draft a migration playbook aligned with protocol-layer PQ work, and (3) coordinate with the EF PQ team so that Lido node operators are migration-ready well before any hard fork mandates it.
Motivation
Ethereum’s consensus layer relies on BLS signatures over BLS12-381, which are not resistant to quantum attacks. While protocol-level migration is an EF/domain concern, the operational burden of key rotation at scale falls on staking infrastructure providers — and no entity carries more of that burden than Lido.
Recent developments make early preparation timely:
• The EF launched a dedicated post-quantum team (Feb 2026);
• EIP-8141 (quantum-resistant accounts) has CFI status for Hegotá;
• The Lean roadmap outlines hash-based signatures across consensus within a 3–4 year horizon.
If migration guidance arrives with a tight fork window, rotating keys across Lido’s distributed validator set without prior rehearsal would be a material operational risk to the beacon chain itself — Lido’s readiness is effectively network readiness.
Proposed Scope

  1. Exposure inventory — map every key-holding surface: validator keys across operators, DVT clusters, CSM, oracle/committee keys, withdrawal credentials.
  2. Migration playbook — draft operator-facing procedures for key rotation under candidate PQ schemes, tested on testnet.
  3. Ecosystem coordination — liaise with the EF PQ team, Obol/SSV, and client teams so Lido’s playbook tracks the canonical migration path rather than diverging from it.
    Deliverables & Timeline
    • Month 1–2: exposure inventory report (public);
    • Month 2–4: draft playbook + testnet rehearsal results;
    • Month 4: final report to the DAO with recommendations for any required budget.
    Budget
    None requested at this stage. Contributions on a volunteer/grant basis; any budget needs would return to the DAO with the final report.
    Closing thought
    stETH’s long-term value proposition rests on being the most operationally robust staking asset. Being the first liquid staking protocol with a published, rehearsed quantum-migration path is a natural extension of that.
2

I appreciate you writing this up as a structured pre-proposal; the inventory → playbook → coordination shape is right, and it’s roughly how Lido Contributors have been thinking about it already on our end.

Point by point:

(1) Exposure inventory: agreed this is the right starting point, and we’ve actually already started some early internal scoping along these lines. Still early: more “figuring out what we don’t know yet” than anything close to a report, but the thread is live and there is a group of contributors investigating this internally.

(2) Migration playbook: this is where we think it’s too early to commit to anything concrete, deliberately. The actual migration primitive, how account-level PQ support lands via Hegota, and what “migration-ready” will even mean at the consensus layer are still being worked out at the protocol-research level. Writing a Lido-specific playbook ahead of that risks optimizing for a process that gets significantly revised once the canonical path firms up.

(3) Ecosystem coordination: also already underway, informally. Some of us are going into upcoming cross-client/research discussions where exactly these questions — candidate schemes, sequencing, what coordination with staking infra should actually look like — are on the agenda. We see that as the right way to find out what coordination with EF/Obol/SSV/client teams should look like, rather than proposing a liaison structure before we know what there is to liaise about.

Put together: (1) and (3) are already moving, in an exploratory way; (2) is the piece we want to hold off on until the first two give us something real to write down. Once that happens, reconvening here to scope the working group you’re describing — inventory first, same as you proposed — seems right. If you want to be involved hands-on (inventory especially could start independent of protocol-layer uncertainty), say so here and we can loop you in.

I totally agree that that visible preparedness is good for stETH and for the network. We’ll post here as the exposure inventory and the ecosystem conversations give us something concrete, and we’d genuinely rather get pushback from the community along the way than only once there’s a final report to react to.

Thanks for pushing this forward.

3 Likes