A validator's deposit is the actual security in proof of stake

Inherited archive entry · retained from the earlier edition. Its factual, legal and policy claims have not all been reverified for 19 September 2026. Research scope.

The deposit is the bond, not just the entry fee

To become a validator, an account deposits 32 ETH and takes on two duties: attesting to blocks it considers valid, and, when selected, proposing one. Ethereum's consensus documentation frames the deposit as what makes the system's security claim work at all, stating that reverting a finalized block would require an attacker to lose 'at least one-third of the total supply of staked ether'. The exact rules governing what counts as a violation and how penalties are computed live in the consensus-layer specifications, the reference document client teams implement against.

Two penalties that are often conflated

The documentation draws a sharp line between slashing and an inactivity leak. Slashing applies to a validator caught in dishonest, provable conduct: proposing two different blocks for the same slot, or submitting contradictory attestations, both forms of equivocation that a signature makes provable after the fact. An inactivity leak is not dishonesty; it applies when the chain fails to finalize for more than four epochs, and it gradually reduces the stake of validators not voting with the majority, whether because they are offline, misconfigured, or genuinely backing a minority view. Ethereum's rewards and penalties page states plainly that the penalty for a missed vote 'is equal to the reward the attestor would have received' for casting it, a symmetric, non-punitive design, unlike slashing.

Why the correlation penalty is the real deterrent

A slashed validator faces an immediate, small burn, on the order of 0.0078125 ETH for a 32 ETH validator, followed by a forced 36-day exit during which the stake continues to bleed. The larger consequence is the correlation penalty, calculated partway through that exit window and scaled to how much total stake was slashed across all validators in the preceding 36 days. A single validator slashed alone loses a small fraction of its stake; in a mass-slashing event, the documentation notes that correlated penalties can reach the full value of a validator's stake. This design punishes coordinated or systemic misbehaviour, such as many validators run by one operator equivocating together, far harder than an isolated mistake, which is the substance of describing proof of stake's security as costly to attack: the cost scales with how many validators would need to misbehave together to matter.

Questions to carry forward

• Is a reported validator penalty a slashing event or an inactivity leak from downtime, since the causes and remedies differ?
• How many validators does a given staking operator run behind shared infrastructure, and what would a single fault there trigger?
• Does a staking product disclose its slashing history and how losses were allocated to depositors?

The security of proof of stake is not an abstraction; it is the deposit, the specific conditions that burn it, and the arithmetic that makes coordinated misconduct far costlier than an isolated fault. Reading past a summary to identify which of the two penalty regimes actually applies is where the real information sits.