Set Validator Liquid Staking Cap to 100%
# [PROPOSAL 821] [Passed] Gaia v12 Upgrade Software Upgrade Hey @Cosmic_Validator @CML @Sumit_Redhu , My apologies that the Validator Liquid Staking Cap hasn’t been formally defined or discussed. Let me quickly describe the reasoning behind it. The Validator Liquid Staking Cap is the share of each validator’s total delegated ATOM that can be provided by one or more liquid staking provider(s). For example, if the parameter is set at 80% and a given validator already receives 80% of its ATOM from either LSM tokenized shares or interchain accounts (ICAs) -… Change log • 2023-09-27 Created initial post Referencing Riley’s post from a month ago in the v12 upgrade Summary The Validator Liquid Staking cap is preventing a low-ranked validator from receiving liquid stake. It was never a design intention of the liquid staking module to prevent low ranked validators from getting delegations. Details If there are no objections, the proposal will go up tomorrow, 9/28. Parameter and new value # [PROPOSAL 821] [Passed] Gaia v12 Upgrade “// The ValidatorBondFactor dictates the cap on the liquid shares // for a validator - determined as a multiple to…
Excerpt (1199 of 2515 characters). Read the whole post on the forum ↗
The liquid staking cap is currently set at 50%?
Im not sure I understand. How is the current maximum cap of 250k stATOM insufficient? I realize that’s only Stride and doesn’t encompass all liquid staking providers.
This is the validator liquid staking cap we are discussing here. My understanding is that the liquid staking cap is at 25% globally and 50% per validator.
And you are proposing raising from 50 to 100% per validator? If all validators receive 100% match is the net effect 0?
Also, why the rush to get the proposal on chain vs. taking a week here on the forum to gather feedback?
give us feedback
(you have 10mn to do so)
BlocksUnited: Im not sure I understand. Hi, just in case you didn’t read the explanation from Riley included above: ‘The Validator Liquid Staking Cap is the share of each validator’s total delegated ATOM that can be provided by one or more liquid staking provider(s). For example, if the parameter is set at 80% and a given validator already receives 80% of its ATOM from either LSM tokenized shares or interchain accounts (ICAs) - then Cosmos Hub prevents further LSM tokenizations and ICA delegations to that validator. If the parameter is set at 100% then validators can receive an unlimited amount of liquid staking provider delegations from ICAs, as they can today.’ ‘Thankfully, the attack vector that the Validator Liquid Staking Cap prevents against is fairly unlikely, and this parameter is fully in control of Cosmos Hub governance. So governance can choose to set the parameter to 100%, effectively turning off the parameter. I would recommend that when the liquid staking module upgrade goes live, a governance proposal be introduced to set the parameter to 100%.’ BlocksUnited: Also, why the rush to get the proposal on chain vs. taking a week here on the…
Excerpt (1195 of 1541 characters). Read the whole post on the forum ↗
how many validators gave their feedback ?
why 100% over 80 or 90%
(btw what about the delegators’ feedback - you know, the ones who would bear the slash if an attack occurs)
not saying 50% is good and 100 is bad. just that maybe 5 people’s feedback is a bit thin?
and yeah, even if “unlikely”, there is a vector there 
The Validator Liquid Staking Cap is a safety feature introduced to remove the hypothetical attack scenario where a validator spins up a Cosmos Hub node and delegates everything to that node to attempt an attack on liquidstakedATOM holders.
The attack works like this: a malicious validator could attack liquidstakedATOM holders by liquid staking ATOM to their own validator node, then incurring downtime to slash those delegations made to their own node. Those delegations are entirely liquid staked, so holders of liquidstakedATOM would bear the slash penalty.
@Cosmic_Validator said “So by introducing this cap you are basically setting in stone the current centralization of the Cosmos Hub. Let’s say a small validator contributes a lot and can receive large delegations from liquid staking providers, now because of this cap not possible since can only receive 50% of their current staked ATOM. A cap should be introduced for the larger validators so the centralization doesn’t increase further, not a cap on the small validators also making it even more”
This propsal thats about to go on chain doesn’t limit large validators, correct? The limit would be 100% for everyone so should the proposal be 100% for validators 25-180 for example and not increase the limit for the largest 25?
If you all think this really will protect the smallest validators, please be as descriptive as possible in the on chain proposal. So everybody understands because I didn’t undersend.
doesnt this make it more difficult for small validators? if a validator bonds 1k atom and gets 250k delegations +/- 100% commission they can push out a hard working validator from the bottom of the set. perhaps some Sybil shenanigans
Hi I think you might be confusing the validator bond with the validator liquid staking cap being discuss here. Let’s make an example: imagine a small validator contributing a lot to the Cosmos Hub with 150k ATOM delegation, he is selected by some liquid staking providers to receive let’s say 300k ATOM delegation. However, with the 50% validator liquid staking cap parameter (introduced without any previous discussion in the LSM signalling proposal) this small validator would be able to receive only 150k ATOM from liquid staking providers. In contrast, a large validator with 10M ATOM could receive up to 10M ATOM from liquid staking providers even with this 50% validator cap, therefore this parameter has little effect for large validators but limits further small validators and increases the centralization. Setting this parameter to 100% means disabling it, so that small validators are also able to receive large delegations from liquid staking providers.
Excellent description and answer. I hope your example goes in the on-chain proposal.
why would that matter? are you saying that the LSM prevents LSD providers from having the choice to delegate their own delegations? isnt the point of validator bonding to have skin in the game?
Exactly, the 25% global staking cap parameter and the 250 bond factor were discussed in the previous LSM signalling proposal. However, this 50% individual validator liquid staking cap parameter was introduced silently without any previous discussions (even Jehan/Informal Systems were not aware ‘We did not realize a new parameter had been brought in by the LSM team’) and indeed it limits the amount that liquid staking providers can delegate to validators, even if these validators have enough validator bond. Hence the reason to disable this parameter by setting it to 100%.
Morever, as you suggest regarding the validator bond and the skin in the game, Jehan also mentioned this in the other thread: ‘isn’t this duplicating functionality already provided by the validator self bond param?’
The validator liquid staking cap should be:
100 / T * 0.5 * VP
Where T represents the highest current VP in the set (this needs to update each block or day)
This way the big vals still need skin in the game while the little ones can receive nearly 100%.
Cap for Coinbase Custody: 100 / 7.18 * 0.5 * 7.18 = 50%
Cap for Cosmic Validator: 100 / 7.18 * 0.5 * 0.07 = 0.46%
cc @jacobgadikian & @LitBit
Noam:The validator liquid staking cap should be:
This proposal is not to choose a value for the validator liquid staking cap, the goal is to disable this parameter by setting it to 100% as previously suggested by Riley.
I understand that, but that comes with a potential attack scenario as discussed in this forum thread, right? As such, an ideal outcome would solve for both concerns.
From the other thread regarding this unlikely attack:
Aidan: ‘However, as you point out, the delegation program (and the validator bond factor) help to prevent against this attack’
Riley:
‘Thankfully, the attack vector that the Validator Liquid Staking Cap prevents against is fairly unlikely, and this parameter is fully in control of Cosmos Hub governance. So governance can choose to set the parameter to 100%, effectively turning off the parameter. I would recommend that when the liquid staking module upgrade goes live, a governance proposal be introduced to set the parameter to 100%.’
‘To keep the design simple while adding a bit of extra security, this feature was introduced. But, it’s not strictly necessary, and the safety guarantees provided by the validator bond factor are probably sufficient.’
Thanks for the extra context. I hadn’t fully catched up to the convo and wasn’t aware the “threat” wasn’t really a serious concern.
Hi Noam, this was about a global parameter update.
I like your suggestion though!
I’ll have a peek at the code and see fi we can accomplish that.
Any updates regarding the timeline for this proposal to go on-chain?
CONTEXT: We apologize for the quick comment which doesn’t include our regular in depth analysis of the problematics. On this particular situation we were caught off-guard by this proposal on-chain today. We wish we had the time to get involved sooner in the discussion but we also value to leave our feedback before voting. ANALYSIS: Our stance on the matter is nearly 100% agreed with @Noam and we also recommend to use a formula. Removing security features for the sake that “it poses no threat today” is the number one recipe for disaster in a distant future. Indeed we think that a more conservative approach is required here. We actually think Noam’s formula is quite elegant and does provide a good security distribution along the validator set. Lastly we would also recommend to update that on an epoch basis or at each 21days network “checkmark” to avoid unnecessary regular updates. CONCLUSION: At Govmos (the governance arm of the PRO Delegators’ validator), we emphasize the critical and systemic role that liquid staking can pose to both price stability and network security. The LSM enabling instant conversion to LST has also made significant changes and the consequences of…
Excerpt (1198 of 2049 characters). Read the whole post on the forum ↗
It seems to me that the liquid protocol should be responsible for the equiable staking across validators, and having a robust algorithm (as Noam suggested) to manage this on the protocol layer could help ensure that. The current proposal is not doing enough to make liquid staking equiable, we’ll vote to abstain until a better solution is proposed.
Honestly? Im also fully puzzled to this