Developer input required before implementing
The cutover sequence in this guide determines whether an operator gets slashed, so it cannot be assembled from the existing pages by inference. Please work with the Web3Signer developers to confirm the correct sequence and any waiting periods before writing the page.
Summary
There is no guide covering the move from local validator keys to Web3Signer. Add one that takes an operator through the whole journey, from exporting their existing signing history to cutting over safely.
Current state
The individual pieces are documented, but nothing connects them.
how-to/configure-slashing-protection.md documents importing interchange data with eth2 import --from=<file>. Key loading, slashing protection setup, and the key manager API each have their own pages.
What is missing is the order to do them in, and what makes the transition safe. Searching the documentation for migration or cutover guidance returns only unrelated results about database schema migration.
Why this is needed
Migration is the highest friction moment in adopting Web3Signer, and the moment with the most risk. An operator who starts signing with Web3Signer before their previous setup has fully stopped, or who moves across without their signing history, risks a double signing penalty.
Validator clients document the export side of this from their end, because that is the part they own. None of them can document the import and cutover side, because that part belongs here. The result is that operators currently assemble the procedure from community threads and blog posts, for an operation where a mistake costs real money.
Suggested scope
An end to end sequence, covering:
- Exporting slashing protection history from the existing validator client, in the interchange format defined in EIP-3076. Link outward to each client's own documentation for the exact export command rather than restating their flags, since those change without notice.
- Importing that history into the Web3Signer slashing protection database.
- Loading the validator keys into Web3Signer.
- Reconfiguring the validator client to use the remote signer.
- The cutover itself, including how to be certain the previous signing setup has stopped, and any period an operator should wait before Web3Signer begins signing.
- Verifying the migration succeeded.
Note that EIP-3076 is in Last Call rather than Final, so describe its status accurately. Spell out the standard on first mention, following the terminology rules in this repository.
Verifying technical claims
Do not state any command, option, or behaviour you have not verified. The cutover ordering and any waiting period must come from a maintainer rather than from inference, and should be called out in the pull request for review.
Developer input required before implementing
The cutover sequence in this guide determines whether an operator gets slashed, so it cannot be assembled from the existing pages by inference. Please work with the Web3Signer developers to confirm the correct sequence and any waiting periods before writing the page.
Summary
There is no guide covering the move from local validator keys to Web3Signer. Add one that takes an operator through the whole journey, from exporting their existing signing history to cutting over safely.
Current state
The individual pieces are documented, but nothing connects them.
how-to/configure-slashing-protection.mddocuments importing interchange data witheth2 import --from=<file>. Key loading, slashing protection setup, and the key manager API each have their own pages.What is missing is the order to do them in, and what makes the transition safe. Searching the documentation for migration or cutover guidance returns only unrelated results about database schema migration.
Why this is needed
Migration is the highest friction moment in adopting Web3Signer, and the moment with the most risk. An operator who starts signing with Web3Signer before their previous setup has fully stopped, or who moves across without their signing history, risks a double signing penalty.
Validator clients document the export side of this from their end, because that is the part they own. None of them can document the import and cutover side, because that part belongs here. The result is that operators currently assemble the procedure from community threads and blog posts, for an operation where a mistake costs real money.
Suggested scope
An end to end sequence, covering:
Note that EIP-3076 is in Last Call rather than Final, so describe its status accurately. Spell out the standard on first mention, following the terminology rules in this repository.
Verifying technical claims
Do not state any command, option, or behaviour you have not verified. The cutover ordering and any waiting period must come from a maintainer rather than from inference, and should be called out in the pull request for review.