Governance Slashing

[0xIchigo]

Proposal

If a validator within the superminority fails to vote on a SIMD proposal, they will be slashed 50 BPS upon completion of the voting process.

Note: Failure to vote is defined as complete non-participation in the voting process. It does not matter if a validator votes Yes, No, or Abstain for a given proposal — what matters is that they vote.

Why?

Participation in Solana’s governance is abysmal at best.

For example, the initial advisory vote in October last year had just 14.3% participation. In April, only 53.29% of stake voted on SIMD-0033 regarding Timely Vote Credits. Even for SIMD-0096, a favorable proposal for validators to provide them with the full priority fee, only 51.17% of stake participated.

Something needs to change. And, incentivizing the validators within the superminority (i.e., those with the most stake) to vote is a necessary step toward this.

Prerequisites

This proposal inherently depends on some sort of future slashing implementation, as Solana currently lacks one. However, slashing is on the horizon, as it is presently being tested on testnet. If this proposal graduates from the idea stage to a formal proposal that passes, there is a material possibility that it could be implemented in the near future.

This proposal would also depend on an implementation that tracks validator participation within the protocol. However, this is trivial to implement compared to slashing, as one could easily track validator participation for a given vote by querying the chain.

Potential Next Steps

• Get comments on this proposal and revise it as needed
• Discuss the potential impacts of such a proposal within the research community and with top validators
• Draft a formal SIMD

Appendix

Why 50 BPS?

Fifty basis points (BPS) — or 0.5% — is a nontrivial fraction of total annual yield. If a validator were to achieve approximately 8% annual yield through their participation in consensus and block production, a penalty of 50 basis points would reduce this yield to 7.5% in cases of governance non-participation. This represents a 6.25% reduction in total validator returns, which is a material impact on validator profitability such that the penalty cannot be absorbed as a cost of doing business.

With the current inflation rate around 5%, the proposed penalty represents roughly one-tenth of the annual inflation rate. This proportionality is intentional, as it creates significant economic pressure to drive governance participation among the superminority while remaining well below the threshold that might threaten validator stability or network security.

Moreover, the cost of maintaining and operating governance voting infrastructure is demonstrably lower than the potential 50 basis point penalty. While meaningful, the penalty preserves 93.75% of expected validator returns, thus maintaining the fundamental validator value proposition.

Naturally, if this proposal passes the idea stage, we can reconsider the 50 basis point penalty based on this proposal’s commentary before drafting a formal SIMD. A fixed BPS may lead to a very wide spread in the total actual slashable amount over time as the inflation rate decreases and fees vary each epoch. However, a variable BPS could become increasingly complex and potentially be less punitive over time if it fails to accurately account for decreasing rates of inflation.

Why Not Extend This Proposal to Other Validators?

It is entirely possible for us to crunch the numbers to further break down participation rates within the superminority, supermajority, and long-tail. For now, it would be best to start with the superminority (i.e., the smallest set of validators), assess how this proposal is received, and, if it passes as a formal proposal, critically analyze its effects on incentivizing superminority validators to vote. Expanding this proposal to other validators becomes increasingly complex since the pass criteria enforce no lower bound on participation, and whether it should is debatable and out of the scope of this current proposal.

The goal of this potential proposal is to start incentivizing validators to vote. Beginning with the superminority and going from there seems best, as it’s easier with respect to social consensus to view the top validators as the ones who should have a vested interest in the protocol and its governance.

Most Institutions Don’t Engage in Governance Voting For Legal and Regulatory Reasons

Again, let me reiterate: validators within the superminority should have a vested interest in Solana. Thus, these validators should be participating in governance.

Validators can be thought of as elected representatives within a proportional representation system. When users stake their SOL with a validator, they do not merely seek yield but delegate operational authority and governance responsibility. Validators should, therefore, act as stewards of Solana.

The superminority’s increased voting power through stake concentration creates a corresponding increase in responsibility. With greater stake comes a greater obligation to participate in the protocol’s governance. Validators accepting substantial stake positions implicitly accept a fiduciary duty to act in the best interest of both their delegators and the protocol.

The common institutional argument against governance participation often centers on regulatory uncertainty. However, this is an easy cop-out. Validation itself is an active participation in network governance through consensus. Voting on protocol improvements is a natural extension of this. Additionally, major protocol changes directly affect validator operations and economics. Governance non-participation while maintaining validator operations inherently becomes contradictory.

In response to the argument above, some institutions will likely cite concerns regarding American general partnership law. Here, the problem is that participating in consensus is distinct from governance, such that participating in governance would mean validators are acting as members of an unincorporated entity. The clear innovation here would be to create a governance entity under Wyoming DAO law, in which all validators are members solely to vote for governance proposals.

Of course, our main focus should be building systems that are useful to everyone around the world rather than embarking on noble legal battles. However, what good is a system’s governance if its top stakeholders never participate? How can we enact meaningful change to the protocol when those with the most to say are silent?

If institutions truly believe in blockchains and Solana as leading this future, who better to navigate the legal and regulatory landscape than those with deep pockets and teams of experienced lawyers? Superminority validators with large institutional backings are uniquely positioned to navigate evolving regulatory frameworks while actively participating in Solana’s governance.

[WaggMe]

Plenty of context/thoughts to add here.

Regarding if maximizing voting is the ideal metric:

• Uninformed voting may not be something we should seek to maximize. As an example, SIMD-0088-enable-core-bpf-programs was a complex topic and I would not expect all validator operators to grasp the full range of pros and cons during a voting window. Some will have expertise in networking, some in appchain-specific development, some in financial modelling, and it's better for them not to vote blindly on issues that they feel don't matter to them. "Abstain" is usually pointed to as the solution but in practice many voters go with first-logical-option or crowd-favorite voting when pressured.

• Uninformed-and-mandatory/incentivized voting is net-negative for critical thought in voting participation. Using Jupiter's recent vote participation as an example, many people voted with popular opinion on every vote to (gain an incentive / avoid a penalty). Validators, who categorically automate their operations, would likely automate voting or manually vote "with the crowd".

Regarding actually increasing voting participation:

• many orgs don't want to vote with security-sensitive keys, improving support for designated governance voting keypairs would likely improve this at a small but significant level.

• many orgs may not be aware of governance votes, and a surprise penalty may lead to departures that actually hurt the ecosystem to a meaningful degree relative to the gains this proposal expects from governance participation

• assuming that we know the legal extent of validator operation and governance participation in every country globally is unrealistic. The validators that would be able to afford legal assistance navigating this process would greatly support a smaller number of high-validator-density countries, and would lead to concentration of validator operations which is a net-negative to the ecosystem. The validators at the biggest disadvantage would be small operations that are barely profitable, or those in lower-validator-density countries, as they may choose to cease/reduce/move operations rather than navigating these complexities. This outcome is directly opposite to the network goal of increasing distribution of node operators globally.

Regarding the slashing rate proposed:

• the proposal needs to be clear on if it is slashing 50 BPS (0.5%) of validator stake, validator-and-delegated stake, or reducing upcoming validator yield. Reducing upcoming yield to a validator may be a better incentive for the general public to move their stake to responsible validators and away from those who had their yield reduced for a time period. (Note - the default interpretation from this proposal would be slashing as all stake on a validator, including delegated stake, and as a one-time event per vote).

Regarding only slashing the superminority:

• I think there's going to be large public objection to this, and I can't agree with the application of participation penalties only to the superminority. While analysis may be focused there, introducing slashing that only applies to the superminority effectively only serves to concentrate proportional stake in the supermajority. (Logical experiment: Why would a member of the general public delegate stake or hold LSTs from a superminority validator that can be slashed for missing a vote, when the supermajority is immune to this penalty)

Regarding under-explored risks and impacts of this proposal:

• the secondary outcome of adversarial-SIMDs, that is SIMDs that are intentionally frequent and hard to understand would be a net negative. The incentives that cause this would be validators or other motivated groups attempting to force significant governance burdens in time/effort on validators and causing them to either be slashed or leave, resulting in indirect financial benefit to the motivated actors. Solutions to this could include grace periods after vote participation, needing to miss all votes within a window of time, a ramping yield reduction or slashing penalty, and/or reverse-slashing of the governance proposer if the other validators came to majority consensus.

• the impact of slashing penalties on LSTs needs to be considered, it is still the responsibility of an LST holder to ensure that the validator associated with the LST is a good actor and participating in governance, but the actual outcome of LSTs dropping has wider impacts across the DeFi ecosystem and other areas. This is valid but not yet explored as an impact in this proposal.

My TLDR opinions on these areas:

Regarding if maximizing voting is the ideal metric: it's not, but an incentive model that exists only if validator participation is low could have merit

Regarding actually increasing voting participation: I'd like to see the proposal reconsidered in light of reducing friction to participate, acknowledging that reasonable circumstances may exist that prevent some operators from voting in some regions, and that the proposal is targeting

Regarding the slashing rate proposed: I'm strongly in favor of reducing yield over slashing, as it has the proper impact on general public's due diligence for validators acting favorably for the network.

Regarding only slashing the superminority: My thoughts above are clear, I think this incentivizes the wrong behaviours from general public when deciding where to delegate stake / what LSTs to hold.

Regarding under-explored risks and impacts of this proposal: I have concerns with how this turns SIMDs into an adversarial tool and how this makes supermajority-LSTs into "unslashable LSTs" in the team term, both should be further considered as impacts of this proposal.

[0xIchigo]

Thank you for the feedback!

Regarding Maximizing Voting Participation and Uninformed Voting Risk

This proposal considers abstaining as a valid form of participation. If a validator feels unqualified to make an informed decision on a proposal, they can abstain without penalty. This inherently respects their expertise boundaries while ensuring they're engaged in the governance process.

For Jupiter, many believed that voting "correctly" (i.e., voting for the most popular choice) might net them an extra bonus come time for ASR. However, in the case of Solana's governance, the reward is implementing changes to the protocol that are +EV for the network's success and proliferation. There's no hidden monetary bonus for validators who vote "correctly."

We have the Solana forum for SIMD discussions. This is where validators discuss each proposal, helping other validators understand the issues at hand. Validators also share their reasoning when voting to help encourage deliberation and foster a culture of transparent, thoughtful decision-making. This already helps mitigate uninformed voting. And, at this point, if a validator still doesn't feel they're in a position to make an informed decision, they can signal this by abstaining.

Moreover, if validators were inclined to vote with the crowd merely to align with popular opinion, they would likely already be doing so. However, the lack of current participation indicates that without any clear incentives or penalties, their behavior isn't going to change. By introducing a penalty for non-participation, validators are now encouraged to at least engage with proposals even if they abstain.

Increasing Voting Participation Without Penalties

I'm all ears for ways to improve voting participation without any penalties. Now that people's money is at stake and they are largely interested in the future of Solana's governance, what now? Without a controversial idea like this, it seems that we'd continue business as usual.

We are entering a period of hyper-growth with multiple clients, and significant changes to the protocol are coming to fruition in the near future. Why do we have a stake-based governance meant to decide over these changes if those with the most stake are largely silent? How else would you propose a more informed, active voting populace? A more informed, active voting populace would remedy a lot of these issues surrounding proposal awareness and bring legal and regulator challenges more to the forefront of discussion

Regarding the Slashing Mechanism

The penalty would target the validator's commission/rewards and not the delegated stake. We could target the delegated stake; however, it feels a bit too draconian to punish delegators for a validator's non-participation.

Admittedly, targeting the superminority can be perceived as unfair and could incentivize delegators to move their stake to the supermajority. My reasoning for going with the superminority was that they hold significant influence over the network's security and operations and, therefore, should actively participate in governance. The idea was to start with the superminority to set a standard and then evaluate the possibility of expanding to other validators based on empirical results and community feedback. The aim is to enhance Solana's governance and not penalize arbitrarily.

For the eventual proposal, I am all for dropping the superminority constraint based on community feedback.

Regarding Unexplored Risks and Impacts

To safeguard against potential exploitation, there could be mechanisms where penalties only apply after missing multiple consecutive votes. This would reduce vulnerability to spam or malicious proposals. However, core devs would still need to accept these proposals, so I'm not sure how much of a threat this would be presently. It could definitely be a concern in the future with streamlined voting processes.

Slashing penalties could negatively affect LSTs and, by extension, the broader DeFi ecosystem. However, once we adopt protocol-wide slashing, would thee same concerns not apply to LSTs and need to be navigated?

Ultimately, this eventual proposal would be a non-starter as it would take a long time to actually be implemented (if ever), assuming it is accepted. This would result in a long enough grace period to have these difficult discussions, research, gather feedback, and implement the necessary tools and frameworks to mitigate all of these issues. Without an idea as controversial as this, we'd continue business as usual. Now, we actually having productive talks on Solana's governance. We even finally have Toly talking about slashing on the timeline

[SOELTH]

Why have a superminority constraint at all? This will just encourage sybiling.

If we implement this -- all stake should be eligible for slashing, not just superminority stake.

[bartenbach]

This is what I came here to say. Actually the opposite is probably true as well. I think making sure every node has to vote to prevent slashing actually discourages sybiling.

[t-nelson]

this'll be a nonstarter without first doing the slashing economics legwork. the cited testnet work is for duplicate block violation detection, proof generation and proof verification. no work on slashing economics is in progress

[SOELTH]

If the idea gets traction, there will be people willing to do it.

[0xIchigo]

For sure — the cited testnet work was more about jumping-starting the conversation, as slashing is being thought of in some capacity, albeit not protocol-wide. Starting with governance seems like a good first application of a potential slashing implementation since participation rates are low and those still completely absent from the governance process reap all the benefits without providing anything meaningful back to the network

I also agree with @SOELTH that if the idea gets traction, people will be willing to do the legwork. This idea is intentionally broad since we currently lack the legwork

[kaplanmaxe]

I agree with the idea here, but I disagree with this proposal. In summary, I feel if voted on, the governance process will be taken less seriously, and this feels almost like a coup. I do agree with the idea here, however I have to disagree with the proposal in general.

The main issue I have with this proposal is that it will not be a fair vote. Many of the affected parties by this proposal will not be able to vote for legal reasons, thus it will be completely one sided. This would be equivalent to holding an election but doing everything you can to block one of the political parties from voting.

Many validators in the superminority can't vote today due to legal reasons. I understand that this proposal attempts to address that, and I actually agree with everything being said in it. However, it feels extremely wrong to enforce a penalty on a party who cannot vote on the outcome here. There should be penalties for validators who don't vote if they aren't paying attention. However, there are real legal reasons why some validators don't participate today, and nothing has really been done to address the legal concerns they have brought up.

I've voted on every proposal myself and I actually agree with the ideas here. However, the way this is attempting to be brought to a vote I do not think is fair or right. It sets a bad precedent IMO.

[rexstjohn-anza]

Voting can easily be made anonymous via various zk and other methods. Are you telling me if we did this as a twitter poll and validators voted they could “get in trouble” for expressing a preference? It seems a stretch imo if handled this way.

[0xIchigo]

Another important caveat is that this eventual SIMD, if passed, will be a non-starter — we lack any sort of slashing on Solana and would be bound to wait for its eventual implementation. This would give us a grace period to continue having these conversations about the necessary changes to governance (tooling, the entire system, etc.) while still adding pressure to actually get these things done. Without this idea or added pressure, we'd still have the same system in place with top validators completely disengaged from the governance process while we enter a period of hyper-growth.

I agree with @SOELTH that we need to question why validators who are unable to vote are even validators to begin with. We should consider that every time a validator runs software with new feature gates, they implicitly accept these new features. If they didn't accept these changes, they would run older or modified versions without these new features.

Can't seems to be the operative word here — if this eventual proposal goes to a vote, certain validators can't vote or won't vote? If they can't participate in governance, again, we go back to why these validators are even validators to begin with. In turn, how effective is Solana's stake-based governance if the vast majority of stake doesn't participate?

[kaplanmaxe]

certain validators can't vote or won't vote?

If the answer to this isn't known, that's actually the problem IMO.

• Can't vote: most likely a problem with the governance system
• Won't vote (but can): Should be slashed and shouldn't be a validator

It would be good to understand why the proposal talks about implementing slashing before doing anything meaningful to address the concerns certain parties raised.

Without doing so, it's regulation by enforcement.
With doing so, we could actually have a better governance system, which is also what this proposal aims to address.

[kaplanmaxe]

Voting can easily be made anonymous via various zk and other methods. Are you telling me if we did this as a twitter poll and validators voted they could “get in trouble” for expressing a preference? It seems a stretch imo if handled this way.

All the more reasons why feedback should be sought from the parties that mentioned they "can't" vote. I'm not one of them. But there's been plenty of feedback shared in various channels (note: this isn't directed to you @rexstjohn-anza i am more saying that these parties have shared openly why the governance process is not ideal for them and they would be willing to share).

[0xIchigo]

Without doing so, it's regulation by enforcement. With doing so, we could actually have a better governance system, which is also what this proposal aims to address.

The ultimate aim of this idea is to have productive discussions about Solana's governance. Whether this eventual proposal passes or fails, we now have the largest stakeholders in our current system of governance actively participating in discussions because it is in their best interest to do so.

There are quite a few American-run validators who are fully compliant and voting in Solana's governance today. However, it does seem that many of these validators can but won't vote due to legal/regulatory concerns. Without any incentive to address these concerns, we'd continue business as usual.

The other thing to note is that feature gates are only enforceable by social consensus — it's up to the client developers to implement them and for validators to run their client with or without a given feature set. It's entirely possible that this eventual proposal is accepted by the core devs, passes a validator-wide governance vote, and sits dormant because people don't want to implement it in their clients. Albeit a controversial precedent, this looming threat of slashing could be the necessary fire to actually kickstart more vigorous and proactive discussions and work on resolving issues inherent to Solana's governance.

[michaelh-laine]

First of all, thank you for initiating this discussion, it's important to have these conversations!

This is a complex topic, one the one hand, I would like to see maximal participation in governance, on the other participation just for the sake of it is likely undesirable.

I actually disagree that participation rates in the two SIMD votes earlier this year were abysmal, over 50% participation is decent considering we know a double digit percentage of stake is unable to participate due to their internal compliance/legal constraints and in the absence of fully developed tooling.

Slashing for governance seems premature given a lack of proper infrastructure, what we need is a Realms DAO or similar type setup to properly manage, implement and track votes, leading to a more established and regular cadence of votes, and only then once this is all established we can look at what incentives are needed to improve the process.

Lastly on the proposed penalty of 50bps, this is a bit confusing to me, 50bps of what? On-chain there is no concept of APY beyond credits, which are relative to other validators and differ every epoch. Is the proposal to reduce the points (credits multiplied by stake weight) by 50bps? For one epoch, for one epoch-year? If a validator doesn't participate in 30 votes do they lose 15% of their points going forward?

Attack vector: Could engaged validators set up a large number of votes, knowing some validators won't/are unable to participate, as a way of forcing them to take lower yield (reduction of credits/points of one validator automatically benefits all others through increased yield).

[0xIchigo]

Thank you for the feedback!

~50% participation is a significant improvement from the first few votes and a positive sign for the network. However, we're operating in a stake-based system of governance. When the largest stakeholders with the most to benefit/lose are largely silent, how effective is this system of governance? There are several American-run validators who are compliant and voting today, so it begs the question of why these other validators haven't made, or at least publicly announced that they are making, the necessary steps to improve the situation. It starts to become a question of why do we have validators "participating" in such a mode of governance in the first place? To reiterate what I said above in a previous comment, I'm all ears for ways to improve voting participation without any penalties. Now that people's money is at stake and they are largely interested in the future of Solana's governance, what now? Without a controversial idea like this, it seems that we'd continue business as usual.

I wholeheartedly agree that we need better governance tooling or an overhaul of the system, but nothing has happened since validators started voting — people are content with a select amount of stake participating while others abstain entirely from the entire voting process. If we start talking about it early and if social consensus is for core devs to accept this proposal and validators pass this eventual SIMD, then we will have a long enough grace period to start work on new governance tooling and navigate these complex regulatory and legal issues, now with a more active voting populace. This SIMD is a non-starter and will likely take a long time before implementation, if client devs decide to implement it. However, it'll still be there, putting pressure on people to start having these conversations and forcing them to navigate these issues. That's all that really matters in the end. We're finally having these productive discussions.

To address the specifics of the idea, I guess it makes more sense if the penalty is handed after missing a governance vote but applied after a validator's total rewards for the epoch are calculated based on vote credits and stake weight. So, for example, a validator earns 100 SOL in rewards for a given epoch. Because they missed a governance vote, they would receive 99.5 SOL after the penalty is applied. This way, the penalty applies to the validator's own rewards and does not affect delegators' rewards, as that would be a bit too extreme.

Regarding the potential attack vector, we could look at setting limits on how many proposals can be introduced within a given time frame. Moreover, we could establish some sort of governance committee (a bit more formal than core devs accepting a given SIMD) or preliminary voting to filter out spam or malicious proposals. For example, introducing a cost or stake deposit required to submit a proposal could discourage frivolous or malicious proposals. However, I'm not entirely convinced one way or the other on the best way to mitigate this potential attack vector. What matters, though, is now the community will have to address it, and we can make more informed decisions together

[schmiatz]

Hello guys,
Matthias from Staking Facilities here - first of, thanks for bringing up this proposal and everyone for participating in the discussion. Lots of valuable points that have been raised.
From our perspective, slashing should strictly be reserved for behaviour that is malicious to the network. While abstaining from governance participation is a concern, punitive measures like slashing feel excessively heavy-handed for such scenarios. There’s a risk this could feel more authoritarian and less aligned with fostering meaningful participation. Plus bigger node ops that cross-finance their validator would probably not be converted to voters by simple monetary punishment, while it could be detrimental for smaller ones. In some jurisdiction, participating in voting would require licenses by regulatory authorities, which could be quite the burden for some operators. (on a different note, we as a community could publish a position paper on this for several jurisdictions, thoughts?)
Forcing someone who doesn’t care or lacks the resources or knowledge to meaningfully participate may lead to disengaged or arbitrary voting. Incentives should encourage genuine involvement, not compliance for the sake of avoiding penalties.
The introduction of badges (or similar) on Validator Explorer Websites to signal a validator’s participation—or non-participation—could be a softer approach to foster transparency and accountability within the community.
Voting itself should be more accessible, too. Making the voting experience more user-friendly through a frontend tool, for example, would lower the barriers to engagement. We also recognise that while some SIMDs are technical, validator operators are inherently technical roles. While abstention is always an option, meaningful engagement should be encouraged through accessibility and incentive-driven approaches, not through punishment.
Long way of saying that we’d vote no on this one, although we highly appreciate you raising this topic and taking the first step here.

[cfl0ws]

Introduction

I'm glad to see this proposal out there and bringing this discussion to the forefront. I also think it points out a weakness in the current governance system, e.g. validators voting to implement a system that would put themselves at risk of being slashed.

The other common objection to this approach is that it would cause validators to vote blindly or even write scripts to do a "check the box" vote. That said, I've long felt that any change that causes a validator to have to be even the slightest bit more engaged is a step in the right direction.

Concerns and risk

I agree the legal concerns are worth addressing, however am unsure how much of a difference addressing them and to what extent it would take to increase involvement. At a minimum it would remove, at least partially, one excuse for not participating. I would also caution against giving a pass to "big" validators and not to "small" operators, because the risk is proportionally the same to each operator in its own way. Consistent with this, I would suggest that all validators would be subjected to the voting requirement.

Furthermore, the risk to validators who do participate increases as the size and number of those who don't participate increase. And let's not forget it's the larger operators who have the resources to hire the potentially required legal representation, in house or otherwise.

Additional initial implementation thoughts

While I do feel it's a bit pre-mature to debate the specifics of implementation, here are a few additional, high level thoughts -

1 - Voting non-participation does feel like a slashable condition.

2- Rather than expecting 100% participation, maybe a lower threshold, e.g. 80%, should be considered, to provide some flexibility. Note the threshold should be calculated only on votes a validator was eligible to participate in, i.e. was operating on mainnet at the time of the vote.

3- The implemented slashing penalty could be time-boxed, e.g. until the 80% threshold is reached and exceeded.

Additional requirements

Three things that seem to be required to move this discussion forward -

1 - A slashing mechanism defined and implemented on the network

2- Legal and regulatory concerns addressed

3 - A more stable and mature governance process, implemented on-chain

Conclusion

Increasing governance participation is a worthwhile endeavor. It feels like now is the right time to start this discussion. The proposed slashing mechanism is one lever that can be used to increase governance participation. While there are steps to be taken before this proposal could be implemented, the conversation should continue in parallel to efforts to address the requirements listed above. And in the meantime, other governance participation incentives and disincentives should be explored and discussed.

[Stuffe]

Validators don't vote because things are going well and the proposals aren't that important. If something important comes up, they will come out to vote. This is how it should be, apathetic voting is a very negative thing. Worst case would be that validators vote randomly, which will cripple decision making. Best case would be that validators with no opinion vote abstain, in which case we have gained nothing but an increase in the barrier to become a validator and the risk to stakers.

[bartenbach]

Slashing is a strong action for this. I agree that validators should participate, but disagree that it should only apply to the superminority - and I think slashing is a bit too dramatic (should be reserved for malicious actions).

I think whatever system is implemented should apply to ALL validators regardless of stake, and perhaps a more benign penalty would suffice? Maybe we can just track vote participation and put it on public validator dashboards. That should encourage validators to participate as it gives visibility into their participation, but doesn't actually penalize them if they can't (like mentioned above for legal reasons). This is kind of in the same vein as validators running their own relayers. There really isn't any penalty for using the public ones, but stakers willing to research can easily see that they aren't using best practices. I think that's probably the kind of nudge that vote participation could benefit from. Just name and shame those who don't publicly. Let stake decide what to do with that information.

A simple system like that could suffice. Just bring visibility to participation. If for some reason it's still a big problem for whatever reason, then we could investigate a penalty system - but I don't see that as necessary at this point (although agree we want validators to participate!)