# [PROPOSAL 821] [Passed] Gaia v12 Upgrade

Change log • 2023-08-24 Created initial post • 2023-08-25 Prop on-chain Background The Gaia v12 release is a major release that will follow the standard governance process by initially submitting this post on the Cosmos Hub forum. After collecting forum feedback, a governance proposal will be sent to the Cosmos Hub for voting. On governance vote approval, validators will be required to update the Cosmos Hub binary at the halt-height specified in the on-chain proposal. The roadmap for this and future releases can be found here: informal.systems The Informal Blog - Cosmos Hub January 2023 Update - V8 and V9 Release... Monthly team update covering IBC bug fixes and replicated security launch preparation. Release Contents This release contains the major addition of the Liquid Staking Module and a number of updates to core dependencies. The relevant signaling proposal for the Liquid Staking Module is: • #790. Liquid staking module: Regulated and efficient liquid staking A full changelog and relevant binaries can be found: • https://github.com/cosmos/gaia/releases/tag/v12.0.0 Testing and Testnets The v12…

Excerpt (1192 of 3282 characters). Read the whole post on the forum ↗

Most exciting release in quite some time, bravo

According to github: “// The ValidatorBondFactor dictates the cap on the liquid shares // for a validator - determined as a multiple to their validator bond // (e.g. ValidatorBondShares = 1000, BondFactor = 250 → LiquidSharesCap: 250,000) ValidatorBondFactor = 250 // GlobalLiquidStakingCap represents the percentage cap on // the portion of a validator’s stake that can be liquid ValidatorLiquidStakingCap = 50 // 50% // GlobalLiquidStakingCap represents the percentage cap on // the portion of a chain’s total stake can be liquid GlobalLiquidStakingCap = 25 // 25%” The 25% global cap and the 250 bond factor were mentioned and discussed during the signaling proposal 790. However, this 50% cap on individual validators wasn’t discussed before. 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…

Excerpt (1196 of 1438 characters). Read the whole post on the forum ↗

Hi Cosmic_Validator, Thank you for sharing your well-thought-out concerns regarding the 50% cap on individual validators’ liquid stakes. I wholeheartedly agree that this is a pivotal issue that deserves meticulous scrutiny, as it can potentially impact the very foundation of network decentralization. Your point about the cap disproportionately affecting smaller validators, in particular, is astute and warrants deeper discussion within our community. Given the complexity and importance of the issue, I believe it would be prudent to pursue this topic as an amendment contingent on a Yes vote for the current release. That way, we can progress with the proposed changes while keeping the door open for additional refinements that address your valid concerns. To kickstart the discussion, here are some mitigation solutions that the community might consider: • Tiered Staking Rewards : A system where smaller validators receive slightly higher staking rewards to make them more attractive for staking. This could help in distributing stakes more evenly across the network. • Dynamic Liquid Staking Caps : Instead of a fixed 50% cap for all validators, we could introduce a dynamic…

Excerpt (1196 of 2841 characters). Read the whole post on the forum ↗

CML: Dynamic Liquid Staking Caps : Instead of a fixed 50% cap for all validators, we could introduce a dynamic cap that adjusts based on the size of the validator, allowing smaller validators to offer more competitive liquid staking options. Thanks for sharing your feedback and ideas. I think the LSM, if implemented well, could contribute to improving the network decentralization. However, if not implemented correctly it would just contribute to further centralization. The 250 bond factor was introduced so that depending on this validators are eligible for more or less ATOM to be liquid staked. But the individual validator cap of 50% representing the portion of a validator’s stake that can be liquid should be as you mentioned dynamic and favouring decentralization. The 25% global cap was to avoid liquid staking providers controlling 1/3 of the staked ATOM. But in the Cosmos Hub I’m not aware of any cap on validators to enforce that no validator can get 1/3 of the staked ATOM. What is the justification for this 50% cap for individual validators? Let’s analyse several key points: -With the 25% global cap only around 55M ATOM can be liquid staked. If a few of the top…

Excerpt (1196 of 2173 characters). Read the whole post on the forum ↗

Why this proposal is exempt from the 14 day discussion period.
What is the logic the LSM is following. The team putting forward this proposal could have tried a bit to explain it to people who are going to vote.
There were only 2 parameters which were included in the prop 790.
1 Max liquid stacked amount. 25%
2 validator bond. where 1 token makes you eligible for 250 LS atoms.

But nothing clear on how the validators will be chosen. What will happen when the 25% limit is reached and a big chunk is undelegated then it will lead to more than 25% delegation. Will it automatically remove some tokens from LSM.

There are so many things to be explained and discussed or the hub is only for the people who can dig deep and understand the code. How does team behind this proposal expect the people to vote if they don’t know how things are going to happen.

I just want to speak to the timing and of this prop, and the fact that it is on chain and on forum simultaneously.

The LSM went through months of discussion both before and during the signaling prop: [Signaling Proposal][Draft]Add Liquid Staking Module to the Cosmos Hub - #68 by tom

Then the code went through another month and a half of review here: feat: add LSM to the SDK's v0.45.16-ics-lsm branch by riley-stride · Pull Request #16747 · cosmos/cosmos-sdk · GitHub

We posted this simultaneously to cut down on another month and a half of lead time (2 weeks on forum, 2 weeks in voting + safety buffer on release date). We thought this would be safe given the amount of discussion that has already occurred and how uncontroversial past update props have been. We did not realize a new parameter had been brought in by the LSM team.

If you feel there are still things to change, please vote NO on-chain and we will resubmit. Alternately, if it’s just a param change, then a prop to change the parameter in question can be brought out immediately after this upgrade goes live.

Now, to address the questions about the 50% per validator cap, I will call on @aidan and @zaki_iqlusion

@Sumit_Redhu hey

didn’t this signalling proposal give enough details?

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) - 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. 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…

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

jtremback:

We did not realize a new parameter had been brought in by the LSM team.

Yes, we also didn’t realize because the 50% individual validator cap wasn’t discussed before in the signaling proposal 790, we just noticed about this after checking all the github information in detail. It is not fair to introduce a new parameter like that without previous discussion and with potential major implications regarding stake centralization.

jtremback:

Alternately, if it’s just a param change, then a prop to change the parameter in question can be brought out immediately after this upgrade goes live.

Agree with this, the current proposal will pass and most aren’t aware about this new parameter introduced since even you weren’t aware. A proposal should be submitted asap to remove this new parameter and then this new parameter must be extensively discussed before choosing its value, whether dynamic or other ideas, and when this has been discussed and decided then another proposal can be submitted to add this new parameter.

Cosmic_Validator:

A proposal should be submitted asap to remove this new parameter and then this new parameter must be extensively discussed before choosing its value, whether dynamic or other ideas, and when this has been discussed and decided then another proposal can be submitted to add this new parameter.

Seems like setting the param to 100% would deactivate it

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%. Thank you for the detailed answer. This attack is highly unlikely because currently Stride and pStake are the largest ATOM liquid staking providers and both have delegation programs in place. I don’t think you or pStake will perform this attack. Moreover, the 25% global cap is precisely introduced to prevent liquid staking providers collectively controlling 1/3 of the staked ATOM. The risk however of this individual validator cap is that centralization will increase likely, because this affects especially the smaller validators negatively both because they are unable to receive large delegations from liquid staking providers and they may also lose delegators who want to liquid stake more since they would redelegate to large validators. I fully agree to introduce a…

Excerpt (1194 of 1444 characters). Read the whole post on the forum ↗

should this monitoring happen once an attack is performed, or should we prevent it to happen, even if unlikely, and then increase the cap granularly?

This attack is: Stride, pStake or other ATOM liquid staking providers setting up a Cosmos Hub validator to slash the holders of liquidstakedATOM. Preventing an attack to happen is also done regarding incentives. What incentives Stride has to slash the holders of stATOM? I cannot see any incentives to perform this attack, because this would be like slashing themselves and nobody would liquid stake with them after performing such attack. They could just launch the Cosmos Hub validator and not slash but receive all rewards, but they would be negatively contributing to centralization and it would be like a reputational slash as well. Delegators have the same slashing risks with any validator, and delegators are precisely expected to perform due diligence when choosing validators, similarly they should perform due diligence when choosing liquid staking providers. The serious attack is liquid staking providers controlling 1/3 of staked ATOM but this is already prevented with the 25% global cap for liquid staked ATOM. By monitoring I mean keeping an updated and real-time list of all ATOM liquid staking providers, the amount of liquid staked ATOM each has, to which validators they are…

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

The attack is slightly different. It’s not Stride attacking the Hub; it’s a Hub validator attacking Stride. As Riley said:

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.

However, as you point out, the delegation program (and the validator bond factor) help to prevent against this attack. This would add a bit of extra security and seemed reasonable given only 25% of stake can be liquid (so a validator having nearly 100% of their stake be liquid seems unlikely, or at least implies LSP delegations are imbalanced).

Since it’s a parameter, setting it is up to Hub governance, and it’s easy enough to change!

Well, this is as good a place as any to get to the bottom of this parameter. I have a question: isn’t this duplicating functionality already provided by the validator self bond param?

Riley: This safety parameter demands that the malicious validator must attract non-liquid-staked ATOM in order to accept liquid staked ATOM jtremback: Well, this is as good a place as any to get to the bottom of this parameter. I have a question: isn’t this duplicating functionality already provided by the validator self bond param? I agree, it seems to be duplicating functionality provided already by the validator bond factor. Because the malicious validator would also need to attract non-liquid staked ATOM for the validator bond factor in order to accept liquid staked ATOM? aidan: The attack is slightly different. It’s not Stride attacking the Hub; it’s a Hub validator attacking Stride. As Riley said: Thanks for the clarification Aidan, but didn’t Riley mention the following also?: Riley: The Validator Liquid Staking Cap is a safety feature introduced to remove the hypothetical attack scenario where a liquid staking provider spins up its own Cosmos Hub node and delegates everything to that node to attempt an attack on liquidstakedATOM holders. Here Riley mentions a ‘liquid staking provider’ spinning up its own…

Excerpt (1194 of 1601 characters). Read the whole post on the forum ↗

In theory, validator bond should solve this attack vector. But if validator bond requirements are too high (safer) it’s harder for validators to participate in liquid staking. The X% cap makes it easy for validators to participate in liquid staking, while protecting liquid stakers against the attack described above. It does make the assumption that attacking validators can’t attract 100-X% stake from normal users so it’s not perfect. One way to maintain safe liquid staking and guarantee inclusivity for all validators is to do away with validator liquid staking caps and instead implement different slashing rates for validator bond vs. normal stake. Put simply, slash validator bond before slashing user stake. This is something that’s been discussed with the SDK team for the final version of the LSM that eventually gets upstreamed into the SDK. But, this would be a more involved discussion. 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. Also, @Cosmic_Validator my apologies: my previous response included a…

Excerpt (1194 of 1290 characters). Read the whole post on the forum ↗

Riley:

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.

Yes I agree with this, and @jtremback and others seem to agree as well. So then another proposal should be submitted to set this new parameter to 100% to deactivate it, would the LSM team submit this proposal on-chain or Informal Systems should do it? @Riley

Sounds like a plan. I don’t have anything specific to this proposal. But this made one thing clear, guidelines doesn’t matter when major entities are involved

Hi @Sumit_Redhu , we did have the timeline discussion with the Hub team and the conclusion was that a signalling prop had already been approved, therefore we could expedite this a little. As we can see with the discussion above, there were some elements that still need addressing. We will endeavour to do that for this proposal. For future proposals we will start the forum process earlier so that there is more time for discussion.

For recent past upgrade proposals we gave circa a weeks notice before going on-chain.

Input is welcomed and we try to incorporate as much as possible, while being practical and pragmatic with getting the software ready and released.

Cosmic_Validator:

Yes I agree with this, and @jtremback and others seem to agree as well. So then another proposal should be submitted to set this new parameter to 100% to deactivate it, would the LSM team submit this proposal on-chain or Informal Systems should do it? @Riley

it shouldn’t be deactivated from the start. extra safety is necessary during the early weeks/months of the module, while everyone is measuring LSM’s economics/mechanics/politics impact. it should probably be set higher than the proposed default, but have to exist.

tom: it shouldn’t be deactivated from the start. extra safety is necessary during the early weeks/months of the module, while everyone is measuring LSM’s economics/mechanics/politics impact. it should probably be set higher than the proposed default, but have to exist. Thanks for sharing your opinion. However, Jehan, Riley, Aidan, myself and others think it should be set to 100% since it was introduced without any previous discussion or analysis of the centralization risks it is introducing which are likely much higher than the highly unlikely attack it is aimed at preventing. And this attack is already prevented via the validator bond factor, so this new parameter as Jehan mentioned is duplicating the functionality provided already by the validator self bond parameter. Your arguments provided to keep the parameter are: ‘extra safety is necessary’. Please elaborate more in detail why you feel that attack is not prevented by the validator bond factor and why this new parameter is necessary. So far from the discussion above it is clear that it should be set to 100% with another proposal, and then the value of this parameter whether static, dynamic or other ideas should…

Excerpt (1197 of 1288 characters). Read the whole post on the forum ↗

I’m sorry they just say “a gov vote can/could”, as it’s a possibility.

I didn’t see a strong opinion from any of the participants you mentioned for what this cap should be.

exept from yourself x)

Please elaborate more in detail why you feel that attack is not prevented by the validator bond factor

where did i say that?

i’m just saying it would be better to start with extra safety (even if close to deactivation) and then be more flexible, than having only one safety measure which let some room for a potential malicious actor.

your mind was already made even before you were aware a validator could perform this kind of attack… why being so…sure of this needed deactivation?

CML: I wholeheartedly agree that this is a pivotal issue that deserves meticulous scrutiny, as it can potentially impact the very foundation of network decentralization. Your point about the cap disproportionately affecting smaller validators, in particular, is astute and warrants deeper discussion within our community. Given the complexity and importance of the issue, I believe it would be prudent to pursue this topic as an amendment contingent on a Yes vote for the current release. Sumit_Redhu: Why this proposal is exempt from the 14 day discussion period. What is the logic the LSM is following. The team putting forward this proposal could have tried a bit to explain it to people who are going to vote. There were only 2 parameters which were included in the prop 790. 1 Max liquid stacked amount. 25% 2 validator bond. where 1 token makes you eligible for 250 LS atoms. jtremback: We did not realize a new parameter had been brought in by the LSM team. Riley: I would recommend that when the liquid staking module upgrade goes live, a governance proposal be introduced to set the parameter to 100%. jtremback:…

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

all right then… 1 recommendation.

let’s do it! i would just vote no ^^

I am pleased that this has been a constructive and beneficial discussion and that the community has collaborated on a potential solution. Thanks to all who have contributed to this discussion.

@aidan @Riley @jtremback any updates regarding the governance proposal to set this new parameter to 100%?

I believe @jacobgadikian is planning to submit it once the upgrade goes live.

Yes I am. I’m also going to get it prepared before the upgrade, just to sort of make sure that everything is good to go. I definitely think that we want liquid staking to be able to be the majority of validators stake because when I ran through it it really could affect less well ranked validators, and increase centralization.

Hi @Riley the upgrade went live the 13th September, 10 days later the proposal is still not submitted on-chain, is there any update about this?

Hi Cosmic Validator,

I am interested in know this status also. Did you have an opportunity to participate in the drafting of the proposal. It’s important for the community to monitor the progress of this proposal for the many reasons discussed above.

Hi, no we were not contacted to participate in the drafting but if there are still no updates or replies here in the forum in a week or two then we will take the lead and prepare and submit this proposal on-chain ourselves.

Did you happen to prepare it? If so would you be able to link me to it please!

Putting it up shortly.

Hopefully it won’t be viewed as a violation of procedure that I’m going to say that it was discussed here and I will also create another post here on the forum as well as the governance transaction in the next couple of hours.

Awesome, Chainflow will be supporting it!