# design draft to extend `staking-deposit-cli` for withdrawals validators with the "legacy" `0x00`-type withdrawal credentials will need to issue a one-time message on-chain to change to the `0x01`-type withdrawal credential that points to some address at the execution layer. this document suggests a path to extend the [staking-deposit-cli](https://github.com/ethereum/staking-deposit-cli) to support this operation with the goal of allowing home stakers and other users of this tool a familiar workflow to handle this new action the main purpose of this document is to seek feedback from maintainers and others on the best way to implement this use case ## implementation ### pre-req 1. add the `SignedBLSToExecutionChange` and the `BLSToExecutionChange` type under the `utils.ssz` module ### requirements 1. add a new CLI command `generate_bls_to_execution_change` under the `cli` module 2. validate the necessary parameters from the command line - validator index - execution address (to change to) 3. use the code from the `existing_mnemonic` module to load the user's mnemonic in the new command and produce a `Credential` object 4. assemble a `BLSToExecutionChange` object with the `validator_index`, the `from_bls_pubkey` provided by the `Credential` object, and the `to_execution_address`. 5. sign this data and then assemble a `SignedBLSToExecutionChange` object 6. serialize this object to json and dump to standard out - optionally, take a target file path from the command line ### bonus feature ability to bulk load (validator_index, execution_address) pairs from e.g. a local text file and directions to apply to a subset of the keys reachable from the mnemonic this feature could be scripted if not included in the CLI tooling but it would be nice to have for node operators with many validators ## notes i think we just add a specific command for the `BLSToExecutionChange` message, rather than a more generic "withdrawals credential" switcher as the more concrete thing will be easier to write and test, and it is also not clear we will have a large number of potential switches to make (so any future changes could just leverage the code here as needed) there are luckily not many places a user could mess up here, as all of the data needs to line up for the message to be valid on-chain; in fact, the only security risk i see is if a user makes a correct change message that is somehow leaked ahead of time before they meant to publish the message; to mitigate this risk, we can add a confirmation message that says as much -- "you should only do this when you are ready to publish this message on-chain" consider: do we want to support a (text) file listing pairs of (validator_index, execution_address) to support generating many of these from a single mnemonic? it seems there would need to be one more stream of data mapping secret keys to each pair