# Moving an Ethereum validator safely: slashing-protection records Slashing protection records what a validator has already signed so software can refuse conflicting proposals or votes. When moving a key to another client, transfer the relevant signing history using the supported process, such as EIP-3076 interchange. Stop the old signer before enabling an independent replacement; the history file is not permission to run both at once. Evidence: [Slashing protection interchange format](https://eips.ethereum.org/EIPS/eip-3076) Canonical: https://degreesofsatoshi.com/encyclopedia/validator-slashing-protection/ Published: 2026-10-02 Substantively modified: 2026-10-02 Independently verified by an automated reviewer: 2026-10-02T19:27:58.939Z Data current through: 2026-10-02 AI-assisted research and drafting with a separate automated source-verification pass; no external expert or named human review is implied. ## Key facts - **History:** Key material alone does not contain all prior signing decisions. ([Slashing protection interchange format](https://eips.ethereum.org/EIPS/eip-3076)) - **Interchange:** EIP-3076 defines a format for moving signing history between clients. ([Slashing protection interchange format](https://eips.ethereum.org/EIPS/eip-3076)) - **Network:** The interchange metadata identifies the consensus chain. ([Slashing protection interchange format](https://eips.ethereum.org/EIPS/eip-3076)) ## A restored key can unknowingly repeat a duty A validator can be penalized for signing incompatible messages, including certain proposals or attestations. A new client holding the key may not know that the old client already signed a conflicting message. The protection database supplies that missing context. Preserve it when changing software, recovering hardware or following a supported migration procedure. Evidence: [Slashing protection interchange format](https://eips.ethereum.org/EIPS/eip-3076) ## A backup computer can create a second signer Suppose the old machine loses monitoring connectivity but continues signing. Starting an independent backup with the same key can leave both active. A backup intended to prevent downtime can then introduce a conflicting-signature risk. Confirm shutdown and follow the clients’ migration guidance before enabling the replacement. Coordinate signing history as part of the move rather than treating it as an optional log. Evidence: [Slashing protection interchange format](https://eips.ethereum.org/EIPS/eip-3076); [Home staking Ethereum](https://ethereum.org/en/staking/solo/) ## Check compatibility and import results An interchange file identifies the network and contains validator public keys plus relevant signed-message records. Clients can maintain complete or minimal protection histories, and the interchange rules account for those different strategies. Use the actual client’s supported import and export commands, verify their outcomes and retain secure backups. A valid file format does not certify that every relevant signer or history record was included. Evidence: [Slashing protection interchange format](https://eips.ethereum.org/EIPS/eip-3076) ## Questions ### Is copying the validator keystore enough for migration? No. It provides key material but may omit previous signing decisions. Use the supported transfer of slashing-protection history as well. Evidence: [Slashing protection interchange format](https://eips.ethereum.org/EIPS/eip-3076) ### Can slashing protection guarantee no slashing under all failures? No. Its protection depends on correct client behavior, complete enough history and coordinated operation. Independent duplicate signing remains a material risk. Evidence: [Slashing protection interchange format](https://eips.ethereum.org/EIPS/eip-3076) ## Claims and scope ### validator-slashing-protection-quick-answer Slashing protection records what a validator has already signed so software can refuse conflicting proposals or votes. When moving a key to another client, transfer the relevant signing history using the supported process, such as EIP-3076 interchange. Stop the old signer before enabling an independent replacement; the history file is not permission to run both at once. Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null} ### validator-slashing-protection-fact-history History: Key material alone does not contain all prior signing decisions. Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null} ### validator-slashing-protection-fact-interchange Interchange: EIP-3076 defines a format for moving signing history between clients. Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null} ### validator-slashing-protection-fact-network Network: The interchange metadata identifies the consensus chain. Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null} ## Sources - [Slashing protection interchange format](https://eips.ethereum.org/EIPS/eip-3076) — Ethereum Improvement Proposals. Signing-history transfer between validator clients does not authorize concurrent independent copies. Locator: Interchange format; import and export; safety. Retrieved: 2026-10-02T18:55:26.323Z. - [Home staking Ethereum](https://ethereum.org/en/staking/solo/) — ethereum.org contributors. Running and maintaining execution, consensus and validator infrastructure with a qualifying stake. Locator: How it works; responsibilities; requirements. Retrieved: 2026-10-02T18:55:25.708Z. ## Revision history - 2026-10-02: First publication after primary-source research and separate automated verification. ## Cite this entry Degrees of Satoshi editorial project. “Moving an Ethereum validator safely: slashing-protection records.” Published 2026-10-02; updated 2026-10-02. https://degreesofsatoshi.com/encyclopedia/validator-slashing-protection/