CHIPs discussion phase: Adding Utility to Validator-Bond

Hub Proposals CHIPs
1

Introduction:

We would like to propose adding new features to the current validator-bond parameter. Presented as a way to make validators have some “skin in the game”, we thought this idea could be pushed further in that direction. We think it could become a transparent slashing insurance, being slashed primarily before the delegators’ stake. We will elaborate on the benefits through this post.

Context:

The validator-bond is a particular transaction type within the staking module of the Cosmos SDK, primarily utilized in the Liquid Staking Module (LSM) context. It currently employs a 250x parameter, requiring each validator to bond a specific amount to accept liquid staking providers’ delegations. In simpler terms, a validator must bond 1 ATOM to be eligible to receive up to 250 ATOMs in liquid stake delegations.

1. Validator-Bond Mechanism:

A delegator (or validator operator) can convert a delegation into Validator Bond by signing a ValidatorBond message. The message is exposed by the staking module and can be executed as follows:

gaiad tx staking validator-bond ValidatorAddress --from mykey

To convert a validator bond into regular delegation, you can either unbond or redelegate the shares. This action decreases the validator bond linked to a validator. If reducing the validator bond for a delegator would result in more than 250 times the new validator bond being delegated in liquid staked ATOM to that validator, the unbonding or redelegation won’t be successful. In this situation, the delegator won’t be able to unbond until the amount of ATOM liquid staked to the validator decreases, or the validator bond increases.

2. Slashing Mechanism:

Slashing occurs under several conditions, notably:

  1. Double Signing: A validator signs two different blocks at the same height on the same chain, indicating a double-spend attempt or equivocation.
  2. Downtime: A validator fails to participate in the consensus process for a specified period, missing block proposals and validations.
  3. Invalid State Transitions: Proposing blocks that result in invalid state transitions.

The slashing mechanism in the Cosmos SDK is implemented through the x/slashing module. This module handles evidence of misbehavior and imposes penalties accordingly. The x/staking module interacts with the slashing module to apply penalties, which involve:

  • Token Reduction: A percentage of the validator’s staked tokens is burned or redistributed.
  • Jailing: The validator is temporarily suspended from participating in consensus, preventing further damage.

3. Slashing Insurance Mechanism:

The concept relies on a “validator-bond”, separate from regular delegator stakes, which will be slashed first in the event of misbehavior. These bonds serve as collateral, providing an extra layer of security for delegators.
To enable such feature, we would introduce a “Priority Slashing Mechanism”:

  • Slashing Logic: we adjust to prioritize the slashing of validator bonds over regular staked tokens.
  • Slashing Process: Upon detection of misbehavior, the slashing mechanism checks the validator’s bond and the liquid staked delegations. First we deduct the base amount of bond required to sustain the liquid stake multiplier (250x), If the remaining bond is sufficient to cover the penalty, it is slashed. If it is insufficient, the remaining penalty is applied to the regular staked tokens.

4. Adjustable Parameters:

We propose governance can adjust parameters such as the fraction of penalties to be covered by validator-bonds depending on each slashing condition (double signing, downtime, and invalid state transitions). We propose to initially enable this mechanism for downtime only as they currently incur a minimal 0,01% slashing penalty.

5. Network Benefits:

  • Incentive Structure: Validators are incentivized to maintain sufficient bonds to attract delegators. Delegators are more likely to stake with validators who maintain higher bonds, perceiving lower risks.

  • Economic Security: The slashing insurance mechanism enhances economic security by ensuring that validators have a significant stake at risk, deterring misbehavior more effectively. Validators are directly penalized, protecting the network and its participants.

  • Trust and Participation: Delegators are more likely to participate and stake their tokens when they have assurance that their investments are protected from slashing. This mechanism builds trust within the network, encouraging greater participation.

  • Validator Accountability: Validators are held more accountable for their actions, as they bear the primary financial risk for misbehavior. This encourages diligent and honest behavior, contributing to the overall stability and reliability of the Cosmos network.

Conclusion

The introduction of a slashing insurance mechanism using validator-bonds provides a robust solution to protect delegators from slashing penalties. By prioritizing the slashing of validator-specific bonds, this mechanism offers an on-chain, trustless, and verifiable insurance system. This enhances the economic security of the network, builds trust among participants, and ensures greater accountability for validators. The system is designed to be completely voluntary for validators, allowing them to opt in or out at their discretion.

We hope you will find this proposition valuable and we look forward to gather community feedback and potential improvement suggestions during this discussion phase of the CHIPs process.

Thanks for reading,
Govmos.
pro-delegators-sign

4 Likes
2

The delegated proof of stake (DPoS) model is based on a fundamental principle:
risk sharing between the delegator and the validator.

By delegating their tokens to a validator, delegators express their trust in the validator’s ability to operate securely and protect the network. However, the idea of ​​penalizing the validator’s bond first in case of slashing could alter this principle.

In a DPoS, delegators should be incentivized to choose their validators carefully, because their own stake is at stake.
Delegation represents an act of trust, and this commitment must involve a shared risk. If this risk is transferred primarily to the validator via its bond, the fundamental delegation mechanism could lose its relevance.
Delegators could become less vigilant in their choice of validator, knowing that their risk is diminished, reducing the incentive for accountability and the overall security of the network.

Another argument is that validators could see this model as a double punishment. Not only do they take on the operational responsibility of the node, but they also have to commit a sufficient amount of capital to cover potential losses, thereby increasing the entry costs for new validators.
This could inhibit decentralization, a key element of many DPoS networks, by limiting participation to those with significant resources to risk.

1 Like
3

Unfortunately I think delegators aren’t vigilant for the most part, also considering it can be hard to distinguish excellent and not excellent without spending few hours either looking at data on-chain or reading posts here and there.

Delegators are also suppose to be “consumer” where validators should lean towards professionel business. In a way I don’t think putting “more” pressure on the validators side is bad and I support Govmos idea. The Hub is selling its validators set as main product, the active set should be impeccable more than any others.

I think self bond should be more impacting… we should find a way to rewards somehow validators that put skin in the game and increase self bond token or penalize validators with a minimum bond and living off commissions. (eg : voting power tax, LSM tax…etc)

Also better UX showing more clearly self bond and I hope in the future wallet provider can give better vision of overall validators’ performances

4

Thanks @Govmos for this discussion.

In general, I agree with the approach. I just have some questions to clarify the current draft.

First, can you please correct, as the slashing penalty for downtime is currently at 0.01% on the Hub, not 0.1%.

Then, I have some questions:

  1. Why choose the validator-bond value over the self-bond? The validator-bond is specific to chains with the Liquidity Staking Module (LSM). Making the slashing module dependent on the presence of the LSM would limit its applicability to the Cosmos Hub, requiring a separate maintenance effort.
  2. Am I correct in understanding the adjustable parameters: If the fraction of penalties covered by validator-bonds is set to 50%, would this mean that for a 0.01% slashing penalty, up to 50% would be taken from the validator-bond first? For example, with a top-50 validator having 1 million ATOM delegated, a slashing event would result in a 100 ATOM penalty, with up to 50 ATOM potentially coming from the validator-bond.

I’d like to take the opportunity to address @David_Crosnest concerns.

Evaluating where to stake based on validator-bonds and liquid-staking usage is complex.
To my knowledge, only Moonkitt shows relevant information in a summarized way. When using Mintscan, you need to click on details for one specific validator.

Currently, staking decisions often prioritize factors like airdrop potential or social media presence. Users who look into slash protection details are likely more advanced and make more informed choices, so I would argue they probably wouldn’t be less vigilant in their choice of validator. It’s just an added bonus for validators who have more skin in the game.

Also, if implementing the changes, validators could demonstrate that their “slash protection” claims (that we see in many validators description) are substantiated.

The risk borne by validators is proportional to delegated ATOMs. For example, with a 100% fraction of slashing parameter:

  • Cosmostation would risk 1,300 ATOM for a single uptime slashing event.
  • Crosnest would risk 26 ATOM.
  • With a 50% fraction, these figures would be 650 ATOM and 13 ATOM respectively.

I personally feel that these values should be sustainable for both small and large validators.

Thank you.

Regards,
arlai

1 Like
5

This is precisely why we proposed a system with adjustable parameters to strike the right balance. We also suggested starting with downtime slashing events only, as a test case. Another idea we support is to have the penalty only partially covered, ensuring that this remains entirely voluntary for validators. We still believe delegators should face slashing for validator misbehavior; however, offering an optional incentive mechanism tied to the validator bond presents a potentially valuable solution that warrants exploration.

We fully acknowledge this valid concern, and we agree it must be handled with great care. Fine-tuning the parameters is crucial. As referenced in @arlai-mk’s calculation, a 0.01% slashing event with a 100% fraction (which we do not necessarily recommend) would cost a validator like Crosnest nearly 13 ATOMs. This counters the argument that decentralization would be hampered. However, you’re absolutely right—careful adjustments are essential, particularly if this feature extends to more costly slashing events. We believe the idea of linking validator bonds is worth further consideration and in-depth discussion.