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.
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 be extensively discussed in the forum as well as its implications for stake centralization
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?
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.
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.
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.
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.