[PROPOSAL] [DRAFT] Signalling prop to make LSM opt-in by default

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.


1 Like

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:

  • Deploy staked assets in DeFi
    In this case, I don’t see how this could be a blocker. The user learned he can earn additional yield on his staked $ATOM on top of staking rewards. Maybe this is only my case but I don’t see why I’d be deterred by a 21 days waiting period. My options are remain a native staker or liquid stake to earn more yield, both of which are long term strategies and therefore the 21 days waiting period is in no way a blocker here.
  • Instantly exit his $ATOM staked position
    In this case, I would agree with you. These users want liquid staking instantly which represents a major UX friction to them as they wont be able to exit here and now.
    If the goal of the LSM is to enable this specific use case then perhaps an opt-out by default design is perhaps more suitable for the Hub.

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:

  • Users acquisitions happens at the dApp level.
  • It eliminates any needs to trust third parties for all LSM users.

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

  1. be capable to find a tool such as moonkitt’s/ cosmosrescue
  2. trust moonkitt/ cosmosrescue

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

  1. directly enable the LSM from their favourite dApp ( which they already trust).

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:

  1. Increased awareness regarding the LSM
  2. Popular wallets such as Keplr, Leap, Cosmostation, Xdefi to show the information regarding the lock

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.


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

  • there would be a chance of users noticing when it’s unlocking
  • there would be a chance of users to recover their assets, either because they would have disabled it upfront (in an opt-out situation) or because it would have been disabled by default (in an opt-in situation).

I hope this clarifies.

Kind regards,

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.

1 Like

Here’s a suggestion for refining the proposal, focusing on a time-based limit for the Liquid Staking Module (LSM) with two adjustable parameters:

  • A limit to specify the percentage of the stake allowed for liquid staking via the LSM
  • A reset 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.

  • 10%
  • 20%
  • 30%
  • 50%
  • every 24h
  • every 48h
  • every week
  • every epoch (21d)
  • none of these combinations
  • I oppose this solution
0 voters

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:

  • Multiple Staking: If the user stakes another 120 ATOM, can they liquefy more? Different interpretations arise:
    • Can they liquefy based on the total (20% of 200 = 40), exceeding the initial limit within 48 hours?
    • Or just 20% of the new stake (24), leading to potential confusion about limitations based on total or new additions?
    • Or not liquefy anymore, as they reached the limit once in the previous 48 hours
  • Reset Confusion: Let’s say they wait 48 hours with the remaining 80 ATOM. How much can they liquefy then?
    • Can they liquefy the initial 20 again (confusing reset based on initial stake)?
    • Or only 16 (20% of remaining)? This could lead to users never reaching full liquidity.

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.



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:

  • Setting the maximum LSM capacity per period (e.g., 48 hours) to the limit parameter (e.g., 20%) multiplied by the initial stake at the beginning of the epoch.
  • Once a user utilizes the LSM, we will record the increment amount using the blockchain keeper and reset all values when the 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:

  1. The (e.g.) 48h epochs would be the same for everyone (starting and ending at same block),
  2. The chain will “snapshot” how much was staked at the start of the epoch for all stakers, and reset the liquefy counter to 0,
  3. Whenever the user liquefies, it will increment the counter, and allow to liquefy up to (e.g.) 20% of that stake amount during this 48h window, including if the user adds or removes stake during that time,

With the above, I think we still have at least the below issue:

  1. I expect it will be quite confusing for users who would not understand / remember how much they can liquefy at any point in time (how do you know how much staked ATOM you had at a previous snapshot?)
  2. A user won’t ever be able to liquefy all their staked ATOM. Starting at 100 ATOM, they would have, after each iteration: 100 → 80 → 64 → 51.2 → 40.96 → 32.77 → 27.21 → 20.97 → etc. staked ATOMs left.

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.



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:

  • 24h and 20% limit = 5 days.
  • 48h and 20% limit = 10 days.
  • 24h and 25% limit = 4 days.
  • 48h and 25% limit = 8 days.
  • 24h and 34% limit = 3 days.
  • 48h and 34% limit = 6 days.

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:

  1. At each epoch, you would snapshot the amount of stake of all accounts on chain,
  2. After the epoch, the user will be able to liquefy limit % of their snapshoted stake, within the reset duration period
  3. After each reset 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,

1 Like

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.