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

Author Citadel One Background Last year, with prop 790 , the community has voted in favor of adopting the Liquid Staking Module. The objective of the LSM is to regulate liquid staking as well as increase its adoption by introducing the following features: • Cap the amount of $ATOM that could be liquid staked. The initially cap proposed by the LSM is 25% of total $ATOM staked but could be modified by on-chain governance. • Imposing a Validator self-bond requirement to receive delegations from LSD providers with a 1:250 ratio. • Enable instant liquid staking of staked $ATOM, without having to wait for the twenty-one day un-bonding period. The 3rd feature introduced by the LSM is designed to address the opportunity cost incurred by users when switching to liquid staking from native staking: Before, any user with natively-staked $ATOM will have to forego three-weeks worth of staking rewards in order to benefit from liquid staking. This is because they have to un-stake their $ATOM before being able to liquid stake, a process that takes 21 days. The LSM addresses this and eliminates the cost by allowing native stakers to instantly switch to liquid staking. The Liquid…

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

LST as a route to extract tokens on a compromised wallet is definitely a growing trend. I’ve spoken with @ctrl-Felix (Cosmos Shield) about it and have recently seen a thread from @SilkNodes who are inundated with queries from confused wallet holders.

LSM opt-in by default makes sense from that perspective, but I wonder if there is design space to make the window to enable LSM shorter - 3 days vs 21 day?

And if we can couple that with in-browser/in-wallet push notifications on unstaking events

That’s a good point! It was actually what I proposed in the first draft: Opt-in by default + a shorter activation period. Which will enable a better DeFi UX while still giving native Stakers time to attempt assets recovery. In the end, maintaining the same level of security for staked assets pre-LSM made more sense to me.

I’d say 3 days is too short, a week might be better. But I’d be in favour of a shorter enabling period as well, if technically feasible.

I think Keplr offer such notifications but not sure if they involve unstaking events as well.

Agreed, the current ATOM blockchain is full of temptations for airdrops, various advertisements and blogger promotions, slightly different websites and names, and it is very easy to fall into the trap if you drink too much delicious wine.

And it is also a very strange way to exit the necessary third-party tools, which does not seem to take into account the use of trust and security

If feasible, we definitely support research to have a shorter activation period to the LSM which would allow to deactivate it by default, but there might be a dependancy to the regular 21d unbonding period which may prevent us from doing it.

In favor for LSM opt-in by default

It makes no sense that it’s up to the user who doesn’t want to use LSM to make the “research” on how to disable it.

The default state should be the safer one!

Tagging community members & validators that might be interested in providing feedback on the draft @Cosmic_Validator @StakeLab @Ertemann @Polkachu @jtremback @zaki_iqlusion @effortcapital @Elijah @Imperator.co @Allnodes

I suspect that unless wallets start displaying to users their locked/unlocked liquid staking state then making the LSM opt-in instead of opt-out will have zero effect. Because compromised users will just be unlocked, not see anything and then have their funds stolen and the downsides for defi usability are substantial.

https://www.moonkitt.com is the first wallet I’ve seen that has full LSM support.

That’s true, the opt-in won’t increase the security of staked assets. Instead, it maintains the same level of security.

Any user that has staked assets knows that after 21 days, if no actions are taken, they will lose their $ATOM when their wallet is compromised. The same cannot be said for the LSM.
An opt-in model, fixes that:

• If a user is unaware of the LSM, they got nothing to worry about as it doesn’t introduce any additional security concerns.
• If a user is aware, they need to enable it before using it. Thus acknowledging the risks associated with it.

I also agree that LSM support on the wallet level is much-needed. Which is another argument to switch for an opt-in model. We shouldn’t wait for wallets to address a significant change to assets’ safety, as it might take too long. Instead it’s better to be addressed at the protocol level.

We’d support opted out by default with manual opt in

I’m opposed to this proposal for several reasons, but primarily because the proposal as written will not solve the issue that the proposer wishes to solve, and will at the same time make LSM unusable. Impact on the LSM If passed, this proposal would create such a large UX barrier that it would make LSM unusable. The added step of enabling the LSM and waiting 21 days before being able to use the product is more than enough cognitive and interactive user friction to deter a significant number, if not a majority, of the product’s potential users. Users look for immediacy in product usecases. Any delay longer than a few seconds will be unacceptable for nearly all users. It’s well-recognized that increasing UX friction decreases your potential userbase . It’s also well-recognized that Cosmos in particular has a ton of user friction already. The more layers of friction that we add to the Cosmos experience, the smaller the pie grows overall. As there’s no widely distributed front-end to enable the LSM, users would be forced to try to interact with the one very unknown UI that allows for LSM toggling, and there’s a strong likelihood that 99%+ of the potential users of the LSM…

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

Is keplr open source ? Can the community fork it and deploy it’s own version 10x times better ?

Seems like a lot of issues and limitation we face are coming from wallet provider not doing anything…

I agree with @RoboMcGobo ’s take. It’s kind of amazing that racing an attacker to undelegate actually works in some cases, but do we actually know how often that is? It seems like the attackers should be much better at winning that race. Does anyone have any hard numbers on how many people’s funds were saved in an unbonding race before the LSM? And even then, it seems that it would be really hard to get numbers on how many people’s funds have been stolen, so understanding what fraction of cases have been helped by an unbonding race seems very hard to quantify. Digression: I don’t want to derail the conversation but the root of this seems to be the spam issue. This came up last year and we came up with the solution of frontends filtering out proposals with too high a proportion of NWV votes. Using this technique spam proposals are only visible for a short time when they are posted, depending on frontend. We considered building filtering into the Hub’s proposal query endpoint but decided against it because ultimately it’s a cat and mouse game and frontends can adjust more quickly. If people want a more complete solution, then we could suggest that frontends also filter out…

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

RoboMcGobo: If passed, this proposal would create such a large UX barrier that it would make LSM unusable. The added step of enabling the LSM and waiting 21 days before being able to use the product is more than enough cognitive and interactive user friction to deter a significant number, if not a majority, of the product’s potential users. LSM is a staking variant. The problem it solves is that I don’t want to be tied up for a long time! [In this case, why not just ask HUB to shorten the 21 days? Friction already exists in the staking days! The atom war is still going on for even a year. I think the overall economic design is filling holes in the wrong place] LSM represents the free and happy trading that many people want! If you want a good experience, you can trade stATOM directly and enjoy the profits and DEFI perfectly. There is no need to pledge ATOM and there will be no friction issues. If you want airdrops but also want profits and DEFI, you can’t have your cake and eat it too, greedy people will eventually lose your property. Just like ATOM HUB, when you want to do the best, you often go around in circles. There is no absolute perfection, and some…

Excerpt (1198 of 1224 characters). Read the whole post on the forum ↗

Honestly the main problem here is that people click on the provided phishing link in the proposal without even thinking that it might be a scam, i think its pretty basic knowledge to know that when you get your hands on hot wallets you should be really careful with the links. But our job as a community is to cover each other’s backs so i have one idea. You said that legitimate proposals to be hidden until they get the attention of an active validator. The problem with that in my opinion is that i have seen proposals where there is 0 interaction from validators so it could bring some problems. It becomes something like “If validators approve the proposal we can vote on it if not they just dont interact with it and it gets pushed under the carpet”. When a new proposal is open for voting, for the first 12 - 24 hours no text can be copied or link to be clicked in the proposal, BUT only links from absolutely legit/verified sites like forum.cosmos.network which lead to the proposal discussion to be clickable. This way if the proposal is legit people wont have to wait for the cooldown to copy or click the link to the proposal discussion and the forums where they are commented on…

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

I fully agree with @RoboMcGobo and @zaki_iqlusion here. Disabling LSM by default does not help in any way, and staking was never intended to be a way to protect user funds in case of wallet compromise (that’s just a nice side-effect). What I believe is important though, is to raise awareness about the LSM and its features. For full disclosure, I am the main dev behind the LSM wallet mentioned by Zaki above: https://app.moonkitt.com . The main reason I built it is that actually not many people have any clue of what the LSM is: that you can disable the liquefy / tokenize feature, and that you can solidify / redeem liquid staking shares. Most people (if they’ve even heard about it), just know that they can use it to send their stake to Stride and get stATOM in exchange. This is also why I spent a lot of time abstracting the technical constraints of the LSM, and on writing a detailed documentation on the LSM features, that you can find at https://www.moonkitt.com . If you are concerned about the safety of your funds, and disabling the liquefy feature is what you’re after, please feel free to use Moonkitt’s LSM wallet, and also to come back maybe once per week to ensure it’s…

Excerpt (1198 of 1257 characters). Read the whole post on the forum ↗

Thanks for chiming in @RoboMcGobo and expanding on the arguments against an opt-in by design. First, it’s important to clarify that while I believe an opt-in LSM will help reduce spam on the Hub, this is not the main reason for the proposal. I also do not see staking as a security mechanism for assets or a substitution to good OpSec. However, with an opt-out by default design, the LSM introduces a new significant risk to staked assets that didn’t exist before and which many stakers aren’t aware of. When considering that a significant number of native stakers , the potential LSM user base, are introduced to the LSM for the first time as the reason why their staked assets instantly disappeared. It’s hard to not to draw the conclusion that the current implementation is causing more harm than good to the adoption of the LSM. The main objective of the proposal is to introduce, what I believe to be, a better implementation for the LSM. And increase its adoption in the long term. Impact on the LSM: Cognitive Friction: RoboMcGobo: If passed, this proposal would create such a large UX barrier that it would make LSM unusable. I fully disagree with this. While…

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

jtremback:

And even then, it seems that it would be really hard to get numbers on how many people’s funds have been stolen.

I think this is the right question to ask rather than the likelihood of recovering assets that are in the process of unbonding.
But it is a hard question to answer still. However when considering how recurrent the spam proposals are even though they end up being vetoed, one could assume that the funds stolen are higher than the cost of proposals which at the moment is more than 11k $ATOM ( assuming these spams are executed by the same entity.

I also think that filtering-out props without a single non-NWV votes is a great initiative regarless of the outcome of this proposal. How do you suggest we proceed to make this happen?

That being said I consider the increase in the spam proposals more of a consequence than the problem itself. The problem is a suboptimal implementation of the LSM. I replied to Robo’s thoughts here in case you have some additional thoughts.

Describing the opt-in equivalent to the opt-out is, at best, misleading, if not outright false. Throughout our year of activity as a validator in the ecosystem, we’ve conducted over a dozen rescue operations to safeguard users’ assets from compromised wallets and seed phrase leaks due to phishing attacks. Primarily, we’ve utilized frontrunning attacks, as mentioned by @RoboMcGobo , which involve injecting the signed transaction precisely at the unbonding block. Competing in this realm demands substantial preparation and resources, efforts that most hackers don’t typically undertake unless the victim is deemed worthy of their attention. Until now, we’ve successfully recovered all users’ funds. However, since the introduction of LSM, the security landscape against leaks has drastically shifted. The attacks prompt swift LSM liquidation of ATOMs, leaving the user with an empty wallet. It’s essential to clarify that in such cases, the attackers can only steal ATOMs, as they forced to initiate the regular unbonding of all other tokens. While rescuers can usually recover these leftover funds, affected users still endure significant losses, given that ATOM is typically their largest…

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

JohnMontagu: Saying that nearly all users would deter from using a dApp they are interested in because it takes 21 days to enable their staked assets is like saying users will never unstake their assets because it takes 21 days before they’re liquid. Imo this is a great example to use. I feel it actually proves my point. One impact of long unbonding periods is that they do keep delegation sticky. People are less likely to unstake their assets because that decision has consequences that span a 3 week timescale. People in this space very frequently do not think in terms of weeks and months. When many people want liquid assets from staking, they want them now. I disagree that the only relevant factor to the LSM is the lost opportunity cost of staking rewards. The cost of simply unstaking and waiting the 21 days is roughly 0.6% of the value of your principal. This is less than the average user’s slippage + fees in making a swap on most apps (which many comfortably eat when making a swap). In reality, i’d argue that the long waiting period is actually the main blocker for most people. As you’ve said many times, most people don’t understand the LSM. People that want to use…

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

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

RoboMcGobo: My point is, this is a tradeoff. Making the module opt-in significantly harms usability of the LSM and, as I’ve argued above, makes it effectively unfit for the purposes for which it was launched. The potential gains from doing so should be compelling, and they just don’t seem justifiable here. 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…

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

RoboMcGobo: Imo this is a great example to use. I feel it actually proves my point. One impact of long unbonding periods is that they do keep delegation sticky. People are less likely to unstake their assets because that decision has consequences that span a 3 week timescale. People in this space very frequently do not think in terms of weeks and months. When many people want liquid assets from staking, they want them now. 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…

Excerpt (1198 of 5477 characters). Read the whole post on the forum ↗

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 • be capable to find a tool such as moonkitt’s/ cosmosrescue • 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 • directly enable the LSM from their favourite dApp ( which they already trust). Screenshot 2024-05-14 at 15.09.48 1426×1164 152 KB 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…

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

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.

Regards,
arlai

arlai-mk: • Increased awareness regarding the LSM • Popular wallets such as Keplr, Leap, Cosmostation, Xdefi to show the information regarding the lock 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. arlai-mk: 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…

Excerpt (1193 of 2016 characters). Read the whole post on the forum ↗

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,
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.

Govmos:

set a time-cap to 20% of user stake accepted within the LSM for each period

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.

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…

Excerpt (1198 of 1582 characters). Read the whole post on the forum ↗

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: • The (e.g.) 48h epochs would be the same for everyone (starting and ending at same block), • The chain will “snapshot” how much was staked at the start of the epoch for all stakers, and reset the liquefy counter to 0, • 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: • 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?) • 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…

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

arlai-mk: 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?) 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. arlai-mk: 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. 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…

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

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: • At each `epoch`, you would snapshot the amount of stake of all accounts on chain, • After the `epoch`, the user will be able to liquefy `limit %` of their `snapshoted stake`, within the `reset duration` period • 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 Govmos: 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. 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 Govmos: Nevertheless, the most elegant design would be to allow users to be able to set…

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

arlai-mk:

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.

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.