Ethereum distinguishes routine participation penalties, an inactivity leak during prolonged failure to finalize, and slashing for specified conflicting proposals or attestations. Simply being offline is not one of its slashable offenses. Slashing forces a validator's exit and applies penalties whose severity can depend on other slashings around the same period. Precise numerical parameters change with protocol upgrades, so an old fixed percentage should not be treated as a universal rule.

The distinction changes operational priorities. In an illustrative outage, stopping a broken validator may sacrifice rewards while preventing it from signing contradictory messages. Automatically starting an unsynchronized duplicate can make the situation worse. An incident review should therefore identify the exact signed evidence or missed duty before labelling a loss. A screenshot of a falling validator balance cannot distinguish all these mechanisms.

Read the protocol version, the event type and the applicable penalty calculation together; otherwise ordinary downtime can be misreported as malicious behavior or severe slashing.

Ethereum's consensus specification defines two slashable attestation patterns: distinct votes with the same target epoch, and a vote whose source-to-target interval strictly surrounds another. The relevant comparison is between signed attestation data, not a vague allegation that a validator changed its mind. Signature verification and the validator's slashable state also matter when evidence is processed. The cited Phase 0 specification supplies the foundational condition; later fork rules must be consulted for current surrounding processing and penalty parameters.

Use toy epoch pairs to read the surround rule. A vote from source 2 to target 8 surrounds a vote from source 3 to target 7 because 2 is less than 3 and 7 is less than 8. Two different votes ending at epoch 8 instead illustrate double voting. These numbers are an explanatory exercise, not a complete validator implementation. The lesson is to preserve signing history and compare precise fields. Being convinced that two blocks are both plausible does not authorize a key to sign combinations forbidden by the protocol.

The Cosmos SDK slashing module illustrates why terminology must be network-specific. Its documented model tracks missed signatures over a configured window and can slash and jail a validator after its liveness threshold is crossed. Double-signing evidence can trigger tombstoning, preventing that validator from returning. The module also describes exposure of delegated stake. These are framework capabilities and parameterized rules, not proof that every Cosmos-based chain has identical settings.

Imagine delegating through two interfaces that ultimately select the same operator. Two receipts do not necessarily diversify the underlying signing failure. Before comparing arrangements, identify the chain's parameters, the operator, who bears deductions and whether any advertised protection is a separate contractual promise. Then distinguish temporary jail from permanent tombstoning and from an ordinary voluntary exit. These outcomes have different recovery paths.

Reading the deployed chain's configuration is essential: substituting an Ethereum rule or a framework default can give a delegator the wrong expectation about both loss and access to funds.

EIP-3076 specifies a format for transferring slashing-protection history between Ethereum validator clients. Copying a signing key alone does not tell the new client what the old client has already signed. The document discusses complete and minimal protection databases and the conservative checks needed when information is incomplete. An interchange format supports migration; it does not make concurrent, uncoordinated signing safe.

For an illustrative migration review, trace a validator from client A to client B. Identify when A stops signing, how its protection record is exported, how B checks the network identity, and what B refuses to sign after import. Include clock disagreement and an incomplete export in the exercise. Do not improvise a live migration from this description: use the selected clients' current instructions and preserve their protection data.

The broader engineering principle is precise: backups must retain enough safety state to avoid repeating forbidden actions, rather than merely enough secret material to make a signature.