Lesson 10 — Validator economics — slashing, rewards, attack vectors

Question

Consensus protocols are only secure when the economics line up. Reward honest behaviour, penalise malicious behaviour, raise the cost of attacks above the gain. Read the math + attack vectors.

Principle (minimum model)

• Slashing math (Ethereum, since Electra). Equivocation = immediate penalty of effective_balance / 4096, forced exit, and ~18 days later a correlation penalty of effective_balance * min(3 * recently_slashed_stake, total_stake) / total_stake (slash_validator, process_slashings).
• Reward math (Ethereum). Base reward ∝ effective_balance / sqrt(total_active_balance) (get_base_reward_per_increment), so the yield per validator falls as total stake grows.
• Inactivity leak. When > 1/3 are offline, finality stalls; offline validators lose effective_balance * inactivity_score / (4 * 2^24) per epoch (Altair get_inactivity_penalty_deltas with Bellatrix constants) until chain self-heals.
• Attack vectors and cost. Long-range attack (re-fork from genesis with old keys) → mitigated by checkpoint syncing + weak subjectivity. Finality takeover → needs 2/3 of stake (~29M of ~43.8M staked ETH on 2026-10-28).
• Validator-set centralisation risk. A few large staking pools and operators hold a large share of Ethereum stake. Mitigated by distributed validator technology (DVT) + solo-staker incentives.
• MEV redistribution. Block proposer captures MEV by default; MEV-Boost decentralises this via builder market. Strategic for consensus health.
• Why this matters for L1 design. Every consensus or incentive customisation (Berachain's PoL emissions, Tempo payment-rail validator set) reshapes incentives. Misalign → attacks become profitable.

Worked example + steps

Validator economics — slashing, rewards, attack vectors

Cryptography alone doesn't secure a PoS chain. It can prove that a validator double-signed — but proof is worthless if the validator pays nothing for it. The protocol is safe only when the cost of cheating exceeds the cash you can extract by cheating. That's the economics layer, and it's load-bearing — without it, the elegant 3f+1 quorum math collapses into "they shouldn't double-sign, please."

This lesson is the economics layer: slashing mechanics, attack vector pricing, and how to design slashing for your own L1.

1. The economic security argument

For BFT systems:

• Attack requires controlling > 1/3 of validator stake (to halt liveness) or > 2/3 (to violate safety)
• Stake gets slashed on detected double-sign or surround-vote
• Cost of attack = lost stake on detection
• Benefit of attack = value extractable

Security: stake required > value extractable.

For Ethereum with ~43.8M ETH staked (2026-10-28, from a public beacon node), taking over finality requires 2/3 of it, ~29M ETH. If that stake equivocates, the correlation penalty takes essentially all of it (it reaches the full balance once ≥ 1/3 of stake is slashed together). There's no economically rational attacker; you'd lose more than you could possibly gain.

This is economic security: the protocol is safe because attacking is irrational.

2. The two slashable offenses

In any BFT system that supports slashing:

2.1 Double-signing (equivocation — signing two conflicting messages for the same slot)

Validator V signs Vote(block_A, round_5)
Validator V signs Vote(block_B, round_5)

Both signed by V for the same round. Cryptographically provable — anyone with the two signatures can construct a slashing proof.

Punishment: validator loses some or all of their stake.

2.2 Surround voting

Validator V signs Vote(source: epoch_3, target: epoch_5)
Validator V signs Vote(source: epoch_4, target: epoch_6)

The second vote surrounds the first (later source, later target). This violates safety in Casper FFG specifically. Cryptographically provable.

Punishment: similar to double-signing.

3. The slashing proof

A slashing proof is the two contradictory signed messages. That's it. Submission flow:

sequenceDiagram
    participant Watcher as Slashing Watcher
    participant Chain as Reth EL
    participant State as State

    Watcher->>Watcher: Observe two signed votes from V
    Watcher->>Watcher: Verify both signatures
    Watcher->>Chain: SlashTransaction(vote_a, vote_b)
    Chain->>State: Verify proof on-chain
    State->>State: Slash V's stake
    State->>Watcher: Pay whistleblower reward (small %)

Three properties make this work:

1. Detection is permissionless: anyone watching the network can submit a proof
2. Verification is cryptographic: the chain verifies the two signatures, no oracle needed
3. Reward is small: enough to incentivize watching, not enough to incentivize false reports (which fail verification anyway)

4. The slashing math — how much to slash?

Two designs:

4.1 Flat slash

Slash a fixed % of stake regardless of context. Simple. Ethereum's immediate slash is 1/4096 of effective balance since Electra (before Electra it was 1/32 — 1 ETH for a 32 ETH validator).

Easy to reason about. Inadequate if many validators slash together (a coordinated attack).

4.2 Correlated slashing

Slash proportional to how many validators slashed in the same window. Ethereum does this:

slash_amount = stake * min(slashed_stake * 3, total_stake) / total_stake   # multiplier = 3 since Bellatrix

Where slashed_stake is the stake of all slashed validators in a recent window. If one validator slashes alone, penalty is small. If 33% of validators slash together (coordinated attack), penalty is catastrophic — full stake.

This is the economic moat against coordinated attacks. A small accidental slash costs little; a real attack costs everything.

🔍 Find in repo. Ethereum consensus spec, search for "slashing" or "process_slashing". The exact formula is there. What's the multiplier?

5. Rewards — the other half

Validators earn:

• Per-block reward: small constant
• Attestation reward: for voting correctly on the head
• Finality reward: for participating in finality votes

Annual yield depends on total stake (base reward ∝ 1/√total stake). Compared to slashing risk:

• Probability of accidental slash: very low if you run conservatively
• Immediate cost of an isolated accidental slash: 1/4096 of balance (~0.008 ETH on 32 ETH) plus a small correlation penalty
• But the validator is force-exited and its balance stays locked for ~36 days (8192 epochs), earning nothing; if others were slashed in the same window, the correlation penalty grows fast

So a single accidental slash costs you the position and its income, and possibly much more. The economic incentive is to be careful, not to attack.

6. The attack vectors

What can a malicious validator try?

The first two are slashable = economically irrational. The third (long-range) is blocked by weak subjectivity rather than slashing. The last two require majority capital = economically extreme.

The most realistic attack: liveness halt with 1/3+. This costs you the income from honestly staking, but you don't lose stake. Some attackers might rationally do this for political reasons (e.g., government coercion).

Ethereum halts finalization. Tips keep producing (LMD-GHOST still works). Once finality has been missing for more than 4 epochs (MIN_EPOCHS_TO_INACTIVITY_PENALTY), the protocol's inactivity leak kicks in — non-participating validators lose stake gradually until participating stake drops back to 2/3+. The chain finalizes again, with the inactive validators massively penalized.

Beautiful design: even a 1/3+ attack only halts temporarily, doesn't permanently break the chain.

7. For your custom L1

Designing slashing for Tempo or Hyperliquid:

• Validator set size: smaller = easier to coordinate attacks, so harder slashing required
• Slash amount: should exceed maximum theoretical extractable value from an attack
• Whistleblower reward: Ethereum pays effective_balance / 4096 since Electra; size yours to cover the cost of watching
• Inactivity penalty: necessary if you want resilience to censorship

Real data points: Hyperliquid requires 10k HYPE self-delegation for an active validator and says "there is currently no automatic slashing implemented"; a quorum of jail votes removes a misbehaving validator from consensus instead (staking docs). Tempo's validators are permissioned (threat model).

8. The launch question — slashing at day 1?

Should your L1 launch with slashing enabled?

Arguments for: economic security from day 1, no period of "trust us" Arguments against: bugs in slashing logic are catastrophic, need time to validate

Common pattern: launch with slashing enabled but with a low cap. Catch real bugs without bankrupting honest validators. Raise the cap as confidence grows.

Hyperliquid's docs say it currently has no automatic slashing (jailing is "not the same as slashing") (staking). OP-Stack chains do not slash either (they have no decentralized validator set yet).

9. Practice

Calculate for your hypothetical L1:

1. Validator set size: 50
2. Stake per validator: $10M
3. Total stake: $500M
4. Maximum extractable value per attack (estimate): $200M
5. Required slash %: ? (must exceed extractable value)

What if extractable value spikes to $400M (a big trade settling)? Does slashing still cover?

Final check: in one sentence, why is slashing the economic foundation of BFT consensus? If your answer doesn't reference "attack cost > attack benefit," re-read §1.

Summary (3 lines)

• Slashing penalises equivocation (Ethereum: 1/4096 up front + a correlation penalty that reaches the full balance when ≥ 1/3 of stake is slashed together); rewards (∝ 1/√total stake) align honest behaviour.
• Attack costs: a finality takeover needs 2/3 of ~43.8M staked ETH; long-range mitigated by weak subjectivity. Centralisation risk via staking pools — DVT + solo-staker incentives mitigate.
• Custom L1 consensus must align incentives. Misalign = profitable attacks. Next: final quiz.