Hi @JohnMontagu and @Govmos,
Thanks for your comments here, but I’m still not seeing how you expect a user to recognize their wallet has been compromised if the hackers’ only action is to unlock the LSM on their wallet.
And without any way to recognize they’ve been hacked, how can an opt-in mechanism for the LSM offer them any kind of protection?
Is there anything I am missing?
Thank you.
Regards,
arlai
We value diverse perspectives, as they are integral to fostering a cohesive decentralized community. Allow us to further clarify our stance, as it appears you may misunderstand our proposition. We agree with you that a 21-day activation period for the LSM, coupled with a mandatory opt-in, is simply not feasible. This is not what we advocate for. Instead, we believe we should consider a shorter period that strikes a proper balance in this trade-off.
Upon closer examination, you’ll notice that we also view this as a temporary security measure, awaiting broader awareness of the LSM before considering removing the training wheels. In conclusion, we acknowledge your point that the LSM opt-in shouldn’t be dismissed entirely, given that any alteration could significantly impact adoption. Let’s say we concur with that perspective. Could you provide further insight into why you would oppose our secondary proposition, which demands to set a time-cap to 20% of the account stake accepted within the LSM for each period (48h or more). We find this a very elegant compromise to both offer higher security standards, while maintaining immediate LSM usage, an aspect you seem adamant about not modifying.
Interesting take. Which I think is true in some cases btw. I unbond because I’m not interested in the product anymore and a longer unbonding period won’t prevent me from doing so. The only times I’m deterred from unbonding/ withdrawing is when gas costs are extremely high (not the case for Cosmos dApps).
Same thing with deploying funds to a product: it’s because I really like the product and not because it’s easy to use. But perhaps that’s just me and not the general opinion.
Let’s try and look at this more closely from the pov of potential LSM users. Currently, the potential user base is native stakers who aren’t aware of the LSM. Who if they adopt it, it’s for one of 2 options:
So I guess it depends on the use cases we’re trying to enable with the LSM. And if that use cases is DeFi growth for $ATOM (which is a use case that should be thought of in terms of weeks months and even longer), it’s hard for me to see an opt-in LSM as a UX friction.
I think we’re looking at this in a different way. Maybe because in your opinion, we’re assuming that the majority of native stakers are and will be interested in leveraging the LSM ( which so far isn’t the case).
In my opinion, we’re assuming that we don’t know yet. In which case there could as many users who are not interested in the LSM and some will want to disable it. These users will be required to interact with the LSM to do so and that is an interaction friction. Especially when considering that in the first 3 months there wasn’t a single UI to disable the LSM ( to my knowledge), until Cosmosrescue shipped one.
Yes. It could have also been resolved at the dApp level of dApps seeking to leverage the LSM.
This is imo the implementation issue, the opt-out LSM relied on dApps to provide UIs because they’re incentivized to do so. The only problem is that dApps only enabled the Tokenize shares on their UI ( to my knowledge, but happy to proven otherwise).
An opt-in module fixes that as dApps will be required to provide a UI to enable the LSM as well if they want to compete. Which I think is the optimal implementation case, since:
Indeed, that’s an extreme example which I think proves my point:
Should we disable the un-bonding period by default just in case some people want to use instant liquid staking?
If we’re introducing new features, which is what the LSM is to all previous modules of the Hub and their functions, that fundamentally changes one of the core functions, it should be opt-in by default unless we are sure that all users are aware of it and accept it.
I think of it this way: If we’re introducing a feature to make the unbonding period 0 days or 21 days, depending on each user’s choice. Shouldn’t it be opt-in by default unless, at least, all users know about it?
Exactly, if we both agree that there is, at least, a significant number of the potential user base of the LSM who cannot do these simple actions. Don’t you think that ideally the LSM should be opt-in? Or at least provide these users with the proper UIs/ tools to disable the LSM at the same it was implemented?
Hey @arlai-mk, thanks for joining the discussion and sharing the link to the tool you guys are building.
To answer your question, the purpose of this discussion isn’t how to make a user recognize that their wallet is compromised when the attacker enables the LSM. The purpose is to improve the sub-optimal implementation of the LSM: Since most native stakers aren’t aware of the LSM, it’s best to shift towards an opt-in module (reasoning explained in the replies to Robo).
Also I think Moonkitt’s documentation answers that question:
With the current module, users have to
Given that, the majority of native stakers aren’t going to be making use of the LSM/ don’t know about the LSM. Don’t you think that a opt-in LSM is better? That way users seeking to leverage the LSM have to
That being said, your question is valid. But it’s like asking how “how you expect a user to recognize their wallet has been compromised if the hackers’ only action is undelegate assets”?
This is where I believe tools at the wallet level play a crucial role. Ex: notifications about undelegations/ LSM enabling…
Until then, as you guys have mentioned in the docs, checking once a week to see if its enabled is the best option.
Hi @JohnMontagu,
Thanks for your detailed answer.
For me to agree on the fact that the opt-in could actually be useful in protecting users assets, I would need to see first:
Until then, I still don’t think it can bring any useful protection, as people would not know they should check.
Please note that I am not saying that if we had the 2 above points, we should have the opt-in in place, as I also believe that staking is not intended as part of wallet safeguarding against hacks. But at least that request of having opt-in instead of opt-out would make more sense.
And to reply to your comparison with “how do users recognize they’ve been hacked if the only action the hackers do is to unstake assets”, my answer is: “that’s actually what people recognize and that’s when they contact services like ComosRescue”. They see it because their wallet show it is being unstaked, while they haven’t unstaked themselves.
Regards,
arlai
I actually see these 2 points as strong arguments for an opt-out LSM and not the opposite.
When LSM properly matures and we see significant increase in awareness and adoption. Tooling for LSM management at the wallet level could justify an opt-out LSM and not the opposite.
But until we reach such level of adoption I don’t think waiting for wallets that might or might not integrate tooling LSM is the solution.
The LSM technically modifies the unbonding period to all stakers from 21 days to 0 by default (unless further actions by users are taken to cancel it). Don’t you think that such a significant change should introduced as an opt-in? Because the way it works now, we’re assuming that all native stakers are okay with an unbonding period of 0 days. Which clearly is not the case.
So in your opinion, knowing fully well that there is very little awareness around the LSM at the moment, scenario 2 is better than scenario 1?
Scenario 1: There is a chance users might detect the transaction enabling the LSM and do something about it.
Scenario 2: There is no chance users could recover their assets because the LSM is automatically enabled.
If that is the case, there might be a contradiction with your docs where there is a paragraph titled: Protecting Your Stake from Hackers: Why Disabling Liquefy Matters.
If “Disabling this feature acts as a safeguard against such attacks”, don’t you think that implementing that at the protocol-level is even better?
Sorry if it was not clear in my message. Let me try to rephrase see if it makes more sense.
What I mean is that with the current inexistant/low LSM awareness, and the wallets not showing the status of the lock, there is no chance for users to detect the enabling of LSM on their wallet.
So there is no benefit of the opt-in mechanism.
However, there are drawbacks, such as friction when user wants to sell their staked ATOM immediately and realize they can’t.
I do not have any way of pushing wallets to implement a change, so I am trying to do my bit by bringing awareness with my app and its docs, and have been an advocate of using the lock on Cosmos Rescue for as long as it’s been available.
If awareness increases, and wallets display the lock status, then
I hope this clarifies.
Kind regards,
arlai
I personally don’t want to use liquid staking and don’t intend to use it in the future. And as such I don’t want to have any additional vulnerabilities for my Cosmos appchain holdings due to its introduction. This proposal makes sense and it should be implemented as soon as possible. The period should be the 21 day period and not a shorter period as some have suggested. Wallets like Keplr should also somehow also display that “LSM module disabled” or “LSM module enabled” somewhere because even a 21 day period won’t save if you don’t know that someone has opted you in to LSM. Relying on 3rd party sites to manage this functionality is very clunky and unsafe.
Liquid staking is a hedge fund product. I would estimate that less than 10% of ATOM stakers and users have any interest in LST if Ethereum is any indication where only 7% of ETH is liquid staked. It is absolutely ridiculous to compromise the security of the funds of the 90% of ATOM holders because of the needs of the 10%.
This is a very large security vulnerability for retail investors. We haven’t see many attacks yet because ATOM is not big. If ATOM 10xes the attacks will grow exponentially.
Here’s a suggestion for refining the proposal, focusing on a time-based limit for the Liquid Staking Module (LSM) with two adjustable parameters:
limit to specify the percentage of the stake allowed for liquid staking via the LSMreset duration defining the time frame for resetting the liquid staking limit.We invite the community to voice their preferences for each parameter through this poll, aiming to find the most agreeable compromise.
Hi @Govmos,
Thanks for the suggestion! While time-based limits for the LSM sound interesting, there are some complexities that could impact user experience.
Let’s consider a basic example with a 20% limit every 48 hours. Imagine a user staking 100 ATOM and liquefying 20 (20%). This leaves 80 staked, but what happens next?
Scenario Confusion:
The technical implementation of scenario 2 option 1 (tracking against “initial” stake) seems challenging, while option 2 (tracking against remaining) creates limitations users might not anticipate.
There are likely many edge cases, like unstaking affecting the limit. These complexities could make the system cumbersome for regular users to navigate.
So, at least until the above is clarified and seems easy enough for users to understand, my vote is that I oppose this solution.
Thank you.
Regards,
arlai
Thank you for bringing up the possible confusion caused by unclear rules. While we initially considered this at a later stage, we appreciate your valid point. Firstly, the scenario you described is unlikely to occur. Users with liquid ATOMs will likely opt for more attractive exchange rates on external liquidity platforms rather than using the LSM’s flat conversion rate. However, we need to clarify the limit system.
We propose an epoch-based calculation to address this:
limit parameter (e.g., 20%) multiplied by the initial stake at the beginning of the epoch.reset duration has passed.We recommend basing the reset duration parameter on a number of blocks instead of time for simplicity, which should not add much code complexity. We welcome community proposals for alternative solutions.
Hi @Govmos,
Thanks for pointing out that the scenario I described is unlikely to occur. I agree that it is unlikely, especially for short epoch periods. However, if choosing a 21 day epoch, I am sure it will happen plenty.
So, please confirm if I understand correctly:
With the above, I think we still have at least the below issue:
There may be better options, I have tried to find some, but unfortunately I still don’t see anything that beats being able to fully liquefy when needed.
Thank you.
Regards,
arlai
If implemented, this should be the role of LST provider to disclose that limitation and display the maximum amount a user can funnel through the LSM.
The 21d epoch based suggestion overcomes that issue. By adjusting a short reset duration and the %limit, users would be able to fully Liquid Stake their entire stake in:
This duration will reset if this rolls over an epoch change. Which would reset the snapshot to capture the limit parameter to the new value at the beginning of this epoch. Anyhow we think users shall never seek to liquid stake significant share of their stake. Nevertheless, the most elegant design would be to allow users to be able to set the limit parameter themselves (with a 21d delay to have effective change). Everyone would start with a base setting we would define here with a community consensus, and then they could customize it between 0% (basically turning off the LSM) and 100% (removing the time-cap).
The reason why we proposed this compromise is because it could reconcile both camps, offering an elegant intermediate solution to both allow users to use the LSM instantly (with caps, unless they deem necessary to adjust or remove them entirely), whilst still bringing necessary security against LSM usage in wallet hacks.
Hi @Govmos,
Thanks, I now understand that the reset duration and the epoch are 2 different things.
So let me summarize to see if I understand it correctly now:
epoch, you would snapshot the amount of stake of all accounts on chain,epoch, the user will be able to liquefy limit % of their snapshoted stake, within the reset duration periodreset duration, the counter of how much has been liquefied is reset to 0, thus allowing liquefying of another limit % of their snapshoted stake.I agree that it should work, although I believe that it is quite complex for the common user to understand what they can / cannot do, and when they can liquid stake again.
Informing users
If it were to be implemented, I also agree with the above, and we would include the information in the Moonkitt LSM wallet.
Allowing users to control the limit parameter
While @Govmos suggestion (allowing users to set the limit with a delay) seems like a good solution, it ultimately achieves the same outcome as the original “opt-in by default” approach we discussed earlier.
Remember, the reason for limits is to protect users from hackers stealing their entire stake. If users can set the limit to 100%, it essentially removes that protection. A hacker could simply change it to 100% without the user’s knowledge, wait for the 21-day period, and then withdraw everything, just like the initial “opt-in by default” idea.
Therefore, if our goal is to safeguard users’ assets from complete loss during a wallet compromise (which is truly the only reason for limits), then we should not allow users to control the limit parameter.
Kind regards,
arlai
The reason why we came up with this idea was to overcome the strong opposition the opt-in by default seemed to face. Our first post on this topic attests that we are on your side for a reform toward more security. But as the thread grew, we also found out that @RoboMcGobo might have some worthy arguments too. Hence why we decided that there might be an in-between solution that could maintain immediate use of the LSM whilst also improving the security.
We are eager to listen to the community if anyone has other suggestions. Currently, we believe that an opt-in default for the LSM is unlikely to pass a governance vote. Instead, a more balanced solution, such as adjustments to %limit and reset_duration, may receive backing.
Thank you,
While I personally favor maintaining the current user experience (keeping the “status quo”), I would welcome an on-chain proposal that introduces LSM-specific parameters like epoch, %limit, and reset_duration. Whether these parameters are user-adjustable or not can still be part of the discussion.
My main goal is to increase awareness about the LSM and its potential. Any on-chain proposal that reaches a broader audience aligns with this objective.
Regards,
arlai
I dont understand why and how would this make any improvemtns apart from signing an entity into something, that it can choose to do or not to do anyways…
I don’t believe scam proposals are the primary source of wallets being compromised. Scammers are everywhere and use many many strategies to steal.