What was published and why it is not ready for deployment
The document was written by Kevaundray Wedderburn, Tom Wambsgans and Thomas Coratger. It sits in a separate working branch of the EIPs repository, carries Draft status and uses 9999 as a placeholder number. Its discussion field is empty, while the contract address, request-type byte and activation dates are all marked TBD.
That means the proposal can still change substantially or never enter an Ethereum upgrade. It has not completed the normal discussion process, received a final number or been selected for a specific hard fork. It is best understood as a technical prototype for a possible direction rather than an adopted network decision.
How the contract removes the BLS format constraint
The current deposit contract expects a 48-byte BLS12-381 public key and a fixed-size signature. That interface works for today's validator scheme, but it cannot carry larger post-quantum credentials without a separate redesign.
The draft adds a scheme field and permits public keys and credential metadata up to 8,192 bytes each. Scheme 0 is reserved for BLS, while every other identifier remains unassigned. A future EIP would still need to define a replacement algorithm and its consensus-layer validation rules.
Why the design uses three transition modes
The contract defines disabled, BLS enabled and BLS retired states. Deposits begin disabled, after which the network can accept existing BLS deposits alongside new credential formats. At the final stage, a system call permanently rejects new BLS deposits.
The specification provides no reverse transition. This sequence would give clients, staking services and validator operators time to update tooling before the old scheme is retired. Existing validators and credential validation would still require coordinated consensus changes that the deposit contract does not define by itself.
How the draft fits Ethereum's post-quantum roadmap
The Ethereum Foundation formed a dedicated Post-Quantum Security team in January 2026. Its public roadmap separates four areas: validator BLS signatures, KZG commitments for data availability, ECDSA signatures for user accounts and parts of the zero-knowledge proof ecosystem.
For consensus, researchers are developing the hash-based leanXMSS scheme and leanVM to aggregate much larger signatures. Account signature agility is being explored through account abstraction, while hash- and lattice-based constructions are candidates for commitments and proof systems. The new deposit contract addresses only validator onboarding, not the rest of that migration.
What ETH holders need to do today
ETH holders and validator operators do not need to take urgent action. Ethereum.org says current quantum computers cannot break the cryptography used by the network. Work begins early because changing algorithms, clients and wallets across a decentralized ecosystem can take years.
User-account migration will be a separate task. An account that has sent a transaction has exposed its public key onchain, but exploiting it would require a cryptographically relevant quantum computer. If new signature support is adopted and reaches wallets, users will likely receive a guided migration path rather than interact manually with this experimental contract.
- The draft changes validator deposits, not ordinary Ethereum account signatures.
- No post-quantum algorithm is assigned or activated by the document.
- The 8,192-byte limits leave room for larger keys and credential metadata.
- The roadmap's 2029 target is a planning goal, not a guaranteed date for a complete migration.
