Unveiling SIMD 0204's Inner Mechanics

Validators are important components of every blockchain. This is especially true for Proof-of-Stake (PoS) blockchains that rely on validators for functions like transaction confirmation, block consensus voting, and security. However, although these entities serve important roles in the blockchain’s functioning, not all their activities are beneficial to blockchain health and positive growth. These negative activities are called validator misbehavior1.

Other PoS blockchains like Ethereum, Cosmos, Polkadot, and Tezos have already adopted “Slashing” as a mechanism for punishing validators that engage in these behaviors2. With the release of the SIMD 0204 proposal, Solana takes its first step towards implementing this deterrent to malicious validator activity.

This article takes a detailed look at the SIMD 0204 proposal, explaining what it means, who it affects and its potential impact on Solana’s current economics.

What is SIMD 0204 about?

SIMD 0204 is also called the Slashable Event Verification proposal. It is a proposal that is aimed at introducing a program that verifies and logs proofs that a Solana validator has breached the rules and committed a slashable offense3. It is necessary to point out that SIMD 0204 is not exactly a new concept in Solana, since it was originally created and proposed by Anza on November 26th, 2024. However, some updates have been made to the initial proposal before its re-release last week.

The above definition raises several crucial questions that must be answered to achieve a rounded understanding of what SIMD 0204 is and how it affects Solana. These questions include:

What are Validators, and what do they do?
What is Slashing?
What are Slashable Events?

The following sections dive into the core of each of these questions, detailing what they mean and why they are important. First up, what are validators?

What Are Validators?

Validators on Solana are nodes that participate in the consensus process by validating transactions and voting on block proposals, helping to maintain the security and integrity of the blockchain4. In exchange for their services, validators get rewarded with vote credits. Here, it is important to mention that a validator ONLY earns vote credits if it votes correctly, that is, if it votes for a block that ends up getting accepted by the network.

These vote credits are very important because they serve several purposes. They are used to:

Evaluate reward distribution (determine what percentage of the blockchain’s inflation the validator earns for its stakers as economic rewards)
Judge a validator’s activity, and
Determine a validator’s eligibility for the Solana Foundation’s Delegation Program.

Importance of Solana vote credits

Importance of Solana vote credits

The Solana Foundation Delegation Program is an initiative designed to support network validators whereby a validator receives a delegation from a pool of tokens the Solana Foundation owns. However, before a validator becomes eligible for this initiative, they have to first meet a predetermined set of qualifications known as the Delegation Criteria. The Delegation Program is set up such that each eligible validator receives a stake from the Solana Foundation that’s equal to their own stake in the blockchain5. Delegation plays a very important role in validator functioning because the more tokens a validator has delegated to it, the more often it is chosen to write new transactions to the blockchain ledger. Since validators earn rewards for writing new transactions to the ledger, an increase in delegated tokens automatically results in an increase in rewards earned (both for validators and their delegators)12.

Solana validators carry out a number of different functions, like transaction validation, maintaining the blockchain’s ledger state, boosting security and decentralization, and earning and distributing rewards. However, their primary role in the blockchain involves producing and voting on blocks6.

Types of validators

Currently, Solana has two major types of validators. They include:

Consensus Validators: These are the core validators of the blockchain that are responsible for voting on blocks, validating transactions, and maintaining ledger consistency.
Remote Procedure Call (RPC) Validators: RPC Validators are technically not validators in the sense that they do not have any tokens staked on the network. As such, they cannot participate in transaction confirmation or block consensus voting operations. Instead, their role primarily lies in data provision and the inclusion of transactions submitted by RPC node users in blocks7.

For the sake of this article’s exploration of what SIMD 0204 is and how it affects Solana’s economics, the term “Validator” will primarily refer to “Consensus Validators” described above. Currently, Solana has 1,212 validators on mainnet with a Current Superminority rating of 204. The term “Current Superminority” here means that the top 20 validators on Solana control over 33.3% of stake. This is an important highlight because it speaks to Solana’s decentralization. Solana runs on a Byzantine Fault Tolerant (BFT) consensus model, which provides coverage for up to ⅓ (or 33.3%) faulty/malicious validators. As such, since the 20 Superminority validators control over 33.3% of stake, it means they potentially have the power to disrupt the network8. Read more about the BFT consensus here. This essentially means that the higher the Superminority Number, the better decentralized Solana is.

At first glance, it would appear that the obvious solution to improving Solana’s decentralization is to have more validators. However, the situation is a lot more complex than that. According to a research by Bitget, the annual cost for running a Solana validator can be as high as $60,000. Meanwhile, the average staking rewards for each validator only amount to about $18,3709. Note that this calculation considers other contributing income sources like MEV commission revenue and Delegated Stake Revenue in addition to the Block Reward Revenue.

Source: Bitget

Since MEV rewards and inflation income are more or less fixed, the only feasible way for Solana validators to increase their income is to ramp up the amount of $SOL tokens staked on it. Bitget estimates that validators need to have a minimum of 32,300 staked tokens to be profitable yearly. However, according to this Dune Dashboard, only 29% of current Solana validators actually have over 32,300 SOL tokens staked. This suggests that up to 71% of current validators on Solana are operating at a loss.

Source: Dune

These figures become even more important when you consider the fact that validator operation is actually supposed to be a business model. As such, if validator operators are unable to keep their businesses afloat via normal operations, it increases the tendency for smaller validators (based on tokens staked) to cease operating or explore other means of raising revenue, some of which may not be beneficial to blockchain health.

On one hand, it is understandable that validator operators that are unable to stay afloat via normal acceptable measures would seek alternate means of revenue generation. On the other hand, validators engaging in unhealthy behaviors for the purpose of maximizing revenue generation will prove to be disastrous if left unchecked. That’s where SIMD 0204 and Slashing come in.

What is Slashing?

Consensys defines slashing as the process of penalizing a validator for misbehaving2. In other words, it is a penalty mechanism used to discourage bad validator behavior, and it functions by attaching punishments to certain dishonest or negligent activities by validators. Slashing is unique to PoS blockchains10. In some PoS blockchains (Like Celestia), “Slashing” is also referred to as “Jailing.11”

When a validator gets slashed, they end up losing some or all of their staked tokens. However, it is important to mention that in some cases, the punishments for slashing go beyond just validators to affect stakers too. In some PoS blockchains (e.g. Celestia), delegators also have a percentage of their delegated funds slashed as part of validator punishment. This already raises a lot of significant questions, especially as to the fairness of such a mechanism that punishes delegators for the bad acting of validators, but this point will be explored in depth in the coming sections of this post.

Examples of slashable activities include the following:

Double signing and voting activities –validators propose, sign, and attest two different blocks for the same slot in order to increase their chances of a winning vote.
Liveness faults –validators are expected to keep nodes functioning and participate in consensus at all times. When a validator fails to participate in consensus for a prolonged period, they get slashed.

At this point, it is necessary to point out that while other PoS blockchains like Ethereum, Cosmos, and Polkadot have all implemented slashing to discourage bad acting from validators, Solana has not. However, this could be changing soon since SIMD 0204 lays down the foundational building blocks for this to happen. Note that Solana not having implemented slashing yet doesn’t mean that there are no existing mechanisms for validator punishment.

In the earlier parts of the article, it was proven that validators need to maintain a balance of at least 32,300 delegated $SOL tokens in order to remain profitable. However, amassing such a high volume of liquidity from external sources is often nearly impossible for Solana validators. This is precisely why the Solana Foundation’s Delegation Program exists (to subsidise the cost of running nodes on Solana for validators). Whenever a validator with tokens from the Solana Foundation delegated to it is discovered to be operating maliciously, punishments could involve the withdrawal of the delegated stake, effectively rendering the validator non-competitive.

For example, in June 2024, Solana Foundation removed several validators from its delegation program after it was discovered they had been carrying out sandwich attacks against users in an effort to secure better prices for themselves at the expense of retail traders13. A sandwich attack is a form of exploitation where the attacker manipulates the price of an asset (by front-running and back-running trades) to profit from a victim's transaction (or more specifically, the price difference) while the victim has to deal with inflated transaction costs.

Source: Bein Crypto

Here’s another example: In 2023, it was noticed that validators on Solana were deliberately lagging their votes in order to be sure they picked winning blocks. Unfortunately, these vote-lagging activities prolonged the time it took for consensus to be achieved, ultimately resulting in slower blockchain speeds. SIMD-0033 was proposed to introduce the concept of Timely Vote Credits (TVC) in order to fix this problem. Essentially, the rationale was to reward validators who vote faster with more vote credits than those with higher latency levels14.

From the above, it is clear that blockchains have to take an active stance towards discouraging malicious activity from validators. If these activities go unchecked, they could quite possibly lead to a severe disruption of blockchain activities. In November 2023, Bitcoin Suisse –a staking service for institutional clients had almost 100 validators slashed for trying to publish incorrect data to the blockchain. The total loss is estimated to be close to $200,00015. Meanwhile, since Ethereum introduced slashing in 2020, validators have been slashed over 470 times16. This number could be higher, considering that over 10 million blocks have been produced on Ethereum between 2020 and now (Ethereum introduced slashing in 2020). As such, statistics suggest that slashing is a very effective way to stifle bad acting from validators. However, the question is, since slashing is so effective, why has it not been implemented on Solana yet?

The Problem With Slashing On Solana

At first glance, it appears there’s little to slashing beyond just punishing validators for engaging in malicious behavior. However, upon closer examination, several problems become visible. These include:

Can the slashing mechanism distinguish between innocent mistakes and malicious behaviors?

Validators may experience hardware faults, software bugs, or honest misconfigurations. Automatically penalizing these as if they were attacks risks discouraging participation or over-penalizing contributors acting in good faith.

How does a validator's getting slashed affect stakers who have delegated to them?

Slashing not only hurts the validator but also those who have delegated stake to them. This introduces a layer of risk for stakers, who may be penalized for mistakes they had no control over —potentially reducing incentives to delegate at all. This could, in turn, have a significant impact on blockchain security.

How does slashing affect blockchain latency?

Solana’s high-throughput design relies on fast consensus with aggressive optimizations. Introducing a slashing mechanism requires definitive proof of malicious behavior, and this slows things down when safety violations occur. The network must pause, resolve inconsistencies, and restore consensus before continuing, leading to significant latency spikes.

The goal with slashing on Solana is to maintain low latency while ensuring validators are ONLY punished for malicious acts and not routine errors17. Based on the problems outlined above, it becomes clear that for slashing to be fairly and effectively implemented on Solana, one of the most important things that has to be addressed is the accurate identification of slashable events. This is where SIMD 0204 comes into play.

SIMD 0204: A Closer Look

The SIMD 0204 proposal is directly aimed at creating an enshrined on-chain program to verify proofs that a validator committed a slashable infraction. “Enshrined on-chain program” here means that the SIMD 0204 program will not be a user-deployed smart contract. Instead, it will function as a core component of the Solana blockchain itself (just like how stake and vote programs operate)18. Note that SIMD 0204 DOES NOT make any suggestions as to what punishments erring validators should serve. Instead, it simply tracks and records these infractions, creating reports on-chain for use in future SIMD.

That said, I should mention that the earlier SIMD 0204 proposal by Anza actually specified logarithmic stake slashing as a punishment for erring validators, but in this more recent update, that has been removed. It is my expectation that all talk on specific validator punishments will be centered around future SIMDs. With this, it becomes easier to see why SIMD 0204 is important to the Solana ecosystem. It serves as the foundational building block for the implementation of slashing on Solana. It becomes even more important when you consider that other proposals like SIMD-0212 will directly feed off this one to determine operational specifics.

How SIMD 0204 Works

SIMD 0204 introduces a new feature flag, “create_slashing_program.” When this feature flag is turned on, three important things happen:

A new slashing program is deployed on-chain at a fixed address “S1ashing11111111111111111111111111111111111.”
The code is loaded from a buffer account (S1asHs4je6wPb2kWiHqNNdpNRiDaBEDQyfyCThhsrgv) and copied into a program data account.
Then the slashing program is made immutable by setting its upgrade authority to “none.”

Once the create_slashing_program is active, it has two instructions:

DuplicateBlockProof –which allows it to log evidence that a validator has committed a slashable offence. In the event that the proof is found to be valid, a “report_account” is created to store the proof, and then a “system_program_account” creates the violation report for valid proofs.

Note that proofs will ONLY be recorded as valid if shreds are observed to contradict in such a way that it qualifies as a slashing offence. “Shreds” here refers to actual proof data of wrongdoing.

CloseViolationReport –when a validator is caught committing a slashable offense, the reporter has to fund the PDA account (report_account) to submit proof and metadata of the violation and keep the report active. Once the proof has been processed,CloseViolationReport allows the reporter to close the PDA account and reclaim their lamports.

Note that there is a specific wait period before CloseViolationReport can be enforced. This is to prevent reports from being closed too early. The specific wait time is for 3 epochs.

Mindmap visualizing how SIMD 0204 operates

Key Points To Consider

Validator Identity: Currently, when a validator is reported, the slashing report stores the validator’s node public key, which is essentially the identity of the machine that produced the blocks. However, violations can be “vote types” and “non-vote types”. SIMD 0204 suggests that in future updates, violations that involve votes will instead lead to the report storing the vote account’s public key instead of that of the node. This directly plays into the work being done in SIMD 0108 that aims to create a link between a validator’s “node_pubkey” and vote accounts. This will, in turn, empower the slashing system to be able to accurately track and record all violations.
Slashable Event Logging Impact: SIMD 0204 will be a very effective tool for logging known validator infractions like vote lagging, sandwich attacks and so on. However, beyond that, it also provides the perfect window to detect other lesser-known violations that may be affecting blockchain health. With these detailed logs, it becomes easier to identify and punish violations in real time instead of retrospectively.

SIMD 0204 also serves as a huge step forward in distinguishing deliberate malicious validator behavior from accidental occurrences that occur as a result of factors like validator device malfunction, and so on. This is important because it helps to ensure slashing is both fair and effective, preventing potential validators from getting discouraged due to fears of being unfairly punished for actions beyond their control.
Non-backwards Compatibility: SIMD 0204 is not backwards-compatible. This means that if it is successfully implemented, there will have to be a major upgrade of the validator software to ensure they are able to function properly. Not upgrading will lead to existing programs, tools, and workflows “breaking” or behaving incorrectly. The point of consideration here is how long will a potential upgrade take and what impact it will have on Solana’s blockchain activity.

Economic Considerations of SIMD 0204

At first glance, it appears that SIMD 0204 is a proposal that chiefly affects validators. However, upon digging deeper, it becomes clearer that the impact extends well beyond just validators to include delegators or stakers. In other PoS chains like Celo Protocol and Ethereum, punishment for validators centers around slashing or seizing a portion of their stakes19, 2.

However, it is important to point out that when validators get slashed, a portion or percentage of the validator’s delegated balance is what gets slashed, not specifically staked funds owned by the validator itself. This means that stakers share in the risks of a validator misbehaving. It is my opinion that you could make a case for this being a fair punishment since stakers enjoy a share of the rewards if a validator misbehaves and is not detected. On the flip side, it is necessary to point out that stakers do not really appear to have any control over the activities of validators. As such, punishing them for something they have little to no control over would appear harsh, and it could actually disincentivise potential stakers from participating in ecosystem activities. A reduction in tokens staked will lead to reduced decentralization since smaller validators are likely to become unprofitable and cease operations to conserve liquidity.

It is important that any SIMD building on data provided by SIMD 0204 (like SIMD 0212) tailors slashing punishments such that they are limited to validators actually responsible for these malicious actions, instead of the scorch-earth approach that exists with other blockchains. It is also important that these advancements are able to accurately distinguish between malicious activity and accidental malfunctions to prevent validators from getting unduly punished.

Possible Areas For Future Research

The incentive structure for reporters and how they fit into Solana’s slashing verification activities
The feasibility of isolating validator risks from delegator risks to maintain staker security
Alternative validator punishments to discourage malicious behavior aside from stake slashing
The link between validator profitability and malicious validator activity on Solana

Unpacking SIMD 0204: What’s Really Under the Hood

Table of contents