CHIPs discussion phase: Adding Utility to Validator-Bond

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…

Excerpt (1199 of 5599 characters). Read the whole post on the forum ↗

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…

Excerpt (1199 of 1365 characters). Read the whole post on the forum ↗

David_Crosnest: By delegating their tokens to a validator, delegators express their trust in the validator’s ability to operate securely and protect the network. Delegators could become less vigilant in their choice of validator, 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’…

Excerpt (1195 of 1208 characters). Read the whole post on the forum ↗

Thanks @Govmos for this discussion. In general, I agree with the approach. I just have some questions to clarify the current draft. Govmos: 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,1% slashing penalty. 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: • 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. • 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…

Excerpt (1193 of 3346 characters). Read the whole post on the forum ↗

David_Crosnest: If this risk is transferred primarily to the validator via its bond, the fundamental delegation mechanism could lose its relevance. 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. David_Crosnest: 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 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…

Excerpt (1199 of 1591 characters). Read the whole post on the forum ↗