In the complex world of Ethereum staking, understanding rewards is only half the battle. Before delving into this topic, we recommend reading our companion piece, “Beyond the Basics: Understanding Rewards on Ethereum,” which lays the foundation for grasping the full spectrum of Ethereum staking rewards.
Building on that knowledge, this article takes a deep dive into the intricate landscape of Ethereum penalties, moving beyond the more basic concepts to explore the nuanced mechanisms that can impact your staking rewards. From routine attestation penalties to the more severe consequences of inactivity leaks and slashing, we unpack the various risks validators face and the sophisticated systems Ethereum employs to maintain network integrity.
Penalties on Ethereum
In the same way that properly performing duties can earn validators rewards, failing to perform certain duties carries penalties. More specifically, failing to accurately and promptly attest to the target and source checkpoints carries a penalty roughly equal to the reward that would have been received. The same is true for sync committee participation – for each slot that a validator fails to “sign the beacon block root”, they are penalized.
There are no penalties for failing to attest to the head of the chain (i.e., providing the current beacon block root) nor for failing to propose a block. That said, the opportunity cost for failing to propose a block should not be underestimated.
These penalties for “failing to attest” are expected to be relatively low; approximately 7,000 gwei / epoch, or 0.000007 ETH – a little less than $0.02 at a price of $2,653.53/ETH.
There are other more serious penalties though.
Ethereum’s Inactivity Leak: Understanding Penalties and Network Recovery Mechanisms
Inactivity leak is a rare event. It is a network-wide state during which Ethereum is unable to finalize. This happens when less than ⅔ of validators can agree about the state of Ethereum. Validators that fail to perform their duties during inactivity leak incur additional penalties. Validators that are performant do not gain any ETH during this state as rewards offset penalties.
Inactivity leak penalties start small but increase significantly; this chart shows how the inactivity leak penalty increases with time, assuming the validator is completely offline:
The idea behind the inactivity leak is to ‘heal’ Ethereum in the event it is unable to finalize. This is accomplished by reducing the weight of non-performant validators. Validators that are unable to attest will see their balances decrease relative to performant validators. In the extreme, once a validator’s balance drops below 16.75 ETH it is ejected from the active set. Both of these dynamics work to reduce the weight of troubled validators and push Ethereum back towards finalization.
As mentioned, not all validators experience the same level of penalties during an inactivity leak – performant validators do not experience penalties as the rewards they receive offset any penalties. Each validator has a score related to how well it has performed during a period of inactivity leak. This score determines the penalties that the validator experiences – the higher the score, the higher the penalties. There are two ways to reduce an inactivity score – perform duties as expected, or Ethereum needs to exit an inactivity leak. It takes some time for an inactivity score to disappear entirely. This will mean that even after Ethereum exits the inactivity leak state, some validators could still be facing penalties until their inactivity score drops back down to 0.
Ethereum Slashing: Understanding Equivocation and Validator Penalties
With Ethereum, validators can be slashed for equivocation – effectively voting for two different states simultaneously. Another way to think about this is that a validator either creates a fork in Ethereum or supports one; both are slashable offenses.
This can happen in several ways. If a validator proposes two different blocks at the same height they have committed a slashable offense. Proposing two different blocks at the same time leads to the potential for a fork – a validator’s view of the network will depend on which block they receive first.
With attesting, a validator attesting to two different states within the same slot has committed a slashable offense. Here, the validator is effectively supporting a fork by adding its votes to both branches of the fork.
Another slashable offense is known as a surround vote, which also potentially occurs during attesting.
Surround votes can be complicated to understand; see the diagram below from the Ethereum specs for implementation details. The easiest way to think about surround votes is to picture what an Ethereum fork could look like and imagine different ways that you could attest to support both forks. There’s the example given above – when a validator attests to two different beacon block roots (i.e., two different heads of the chain) at the same time.
There’s also a way to attest to checkpoints that support a fork. Checkpoints divide epochs, more specifically they are the blocks in the first slot of an epoch, if the slot is empty in a particular epoch, then the checkpoint for that epoch is the block in the first slot of the prior epoch (this logic repeats until a block is found in the first slot of the epoch).
The following diagram is taken from an article about Casper FFG – the finality piece to Ethereum’s consensus mechanism. The white and gray bands represent epochs. You can see that the pink arrows and checkpoints surround the purple arrows and checkpoints, i.e., a surround vote. Validator voting for both paths is involved in equivocation. When they vote for checkpoints (a2, a3) and at the same time vote for (b2, b3) they are engaging in a surround vote and are slashable.
Regardless of the type of slashable offense, if caught, the result is the same:
- The process to exit the validator from the active set begins;
- The validator has 1/32 of their balance taken (this will likely change with the Pectra upgrade, see here);
- The validator waits for 36 days, during which it receives penalties for failing to attest amounting to about 0.05 ETH currently
- 18 days into this period a proportional slashing penalty might be levied. Whether or not the penalty is levied depends on how many other validators have committed a slashable offense within a 36-day window – 18 days before the slashable offense and 18 days after. Approximately, if the number of validators – calculated by stake – is less than 1% then the proportional slashing multiple is not applied. If the number is greater than 1% then the multiple is applied. The penalty is three times the % of stake committing a slashable offense. So if 5% of the stake is involved in committing a slashable offense in the 36-day window, validators will lose 3*5% = 15% of their balance.
- The proportional slashing multiplier is meant to punish an attack on the network. The assumption is that an attack on the network will likely involve a high proportion of staked ETH. If ⅓ or more of the stake on Ethereum commits a slashable offense within a 36-day window
Slashing can be a particularly catastrophic outcome. Penalties can be especially high in the event that a correlated slashing multiplier is levied. But even in the absence of this penalty, the requirement to have your validator locked for 36 days and then have to exit and activate a new one, can be very detrimental.
There are some obvious precautions that rely on technologies, like slashing protection and doppelganger programs. A rigorous approach to slashing protection, however, involves much more effort and evolution. It starts with a deep understanding of blockchain technology and is informed by a sound operational philosophy. There is no ‘finish line’ for security and slashing protection nor is it merely a box-ticking exercise. Security and slashing protection is an on-going process of continual improvement.
Figment’s enterprise-grade security and reliability is backed by industry-leading certifications and performance metrics. As a SOC II Type 2 certified staking provider, we demonstrate the highest standards of security controls and operational excellence, while our ISO 27001:2013 compliance ensures internationally recognized information security management practices. Our perfect slashing protection record—with zero slashing incidents across our entire Ethereum validator fleet—speaks to our operational expertise. Figment stands as the trusted choice for institutions requiring bulletproof security and reliability.
Conclusion
As we’ve explored, the penalty system on the Ethereum network is a sophisticated mechanism designed to ensure network security and incentivize the correct validator behavior. From minor attestation penalties to the more severe consequences of inactivity leaks and slashing, these measures play a crucial role in maintaining the integrity of the Ethereum network.
We encourage you to deepen your understanding of Ethereum staking by exploring our additional educational resources. Our articles “Beyond the Basics: Navigating Rewards on Ethereum” provides valuable insights into the risks and metrics that shape validator success.
At Figment, we focus on risk-adjusted rewards to ensure that our customers can optimize their staking rewards while minimizing exposure to potential hazards. As the ecosystem evolves, particularly with upcoming changes like the Pectra upgrade, staying informed and partnering with knowledgeable validators becomes increasingly important.
Meet with us to learn more about Ethereum staking and how we can help you.
