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
We’ll be changing the ValidatorLiquidStakingCap to 100.
Forum post link
IPFS link
Governance votes
The following items summarize the voting options and what it means for this proposal:
YES - Allow validators to recieve up to 100% of their delegations as liquid stake
NO - Make no changes to the Validator liquid staking cap
NO WITH VETO - A ‘NoWithVeto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned.
ABSTAIN - You wish to contribute to quorum but you formally decline to vote either for or against the proposal.
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.
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%.’
(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.
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?’
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.’
