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

Hub Proposals
1

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 Staking Module is enabled on all wallets by default but users could disable it at any moment. Once disabled, the LSM will take a period of 21 days to be enabled again.

While the instant liquid staking feature addresses the opportunity cost, its current opt-out design comes with a significant safety trade-off:

When an LSM-enabled wallet is compromised, there is no chance to recover natively-staked $ATOM. With the LSM, the attacker could instantly liquid stake and take custody of the assets.

This has led to a spike in phishing attacks targeting $ATOM stakers, primarily via spam proposals:

There has been a total of 55 spam proposals on the Cosmos Hub. A total of 50 of these props were posted after the LSM went live and 5 of which are actually in voting period.

All of these props were vetoed, leading to the loss of the proposers’ deposits totalling 11,250 $ATOM, which suggest that the profits from these attacks are higher than that. These phishing activities are liable to increase as most users are still unaware of the LSM and how it affects their staked $ATOM. Read more here.

Description

In this post, I’d like to propose an adjustment to the LSM design to address the discussed safety risk: Make the LSM opt-in by default.

Switching to an opt-in design will require native stakers who seek to leverage the LSM for instant liquid staking to manually enable the LSM and wait a period of 21 days before being able to use it.

Below I present the arguments for this change:

  • No opportunity cost
    The goal of the instant liquid staking feature is to eliminate the opportunity cost of liquid staking. Making the LSM opt-in by default doesn’t change that.

    This is because unlike the un-bonding period of 21 days where users forego any staking rewards, during the LSM enabling period (which also takes 21 days) users can still earn staking rewards. Thus, no opportunity cost.

  • Safety over UX
    The rationale behind the LSM is to ensure that liquid staking growth doesn’t compromise the Hub’s security. This is done by imposing a cap on total LSTs market share and skin-in-the game requirements for Validators.

    It could be argued that an opt-out by default design isn’t aligned with this rationale as it automatically compromises the safety of staked $ATOM: The current design requires native Stakers to manually disable the LSM to retain the same level of security for their assets.
    Ideally, additional actions should be required by users seeking to benefit from the LSM features and not the other way around.

    It’s also worth noting that number of native stakers seeking to leverage instant liquid staking is significantly smaller than those who don’t. Therefore, it makes more sense to have it disabled by default.

  • Complicated process of enabling/ disabling LSM
    In an opt-out design, native stakers are required to manually disable the LSM, a process that is technically challenging for most. This means that users have to rely on front ends/ tools provided by third parties, which introduces additional safety risks.

    To my knowledge, there is a single trusted party (Cosmos Rescue, a Cosmos Hub validator) that allows the disabling of the LSM.

    With an opt-in design, this risk is mitigated:

    First because only users leveraging the instant liquid staking will have to interact with the LSM. Second, LSD providers will abstract away the process of enabling of the LSM. This eliminates any additional trust assumptions as users don’t have to trust any third parties they don’t trust already.

Technical implementation

My understanding from Zaki’s forum post is that due to implementation challenges with how the SDK is currently organized, the LSM currently runs on an SDK branch that is feature-frozen and only allows for security fixes. However, the plan is to implement the LSM as a separate module of the SDK in the future.

For these reasons I propose that, if the signalling proposal passes, the LSM transitions into an opt-in module once the x/fungibility module is shipped.

Conclusion

It’s worth noting that the risks of phishing attacks could be greatly reduced via better screening measures at the wallets/ explorers level. However, I believe that the security risks introduced by the LSM should be addressed at the protocol level for the following reasons:

  • Eliminates relying on any third parties to protect staked assets.
  • Ensure that every user leveraging the LSM fully understands the risks and willingly participates in liquid staking.
  • Guarantees the same security level of staked assets while still eliminating opportunity costs of liquid staking for native stakers.

FAQ

  • What are the downsides of transitioning to an opt-in by default LSM?

    An opt-in design by default will lead to a degraded DeFi UX as it will prevent users from instantly deploying their staked $ATOM to dApps leveraging the LSM. However my point of view is that DeFi UX is far outweighed maintaining the same level of security for staked assets, especially when considering the following:

    • The LSM has been live for a long period, meaning that any users seeking to leverage the instant liquid staking feature have been able to do so.
    • Users seeking to leverage the LSM will only need to enable it once, after that they can instant liquid stake anytime they want.

  • I have used the instant liquid staking feature before, what will happen to my liquid staked assets if this gets implemented?

    If implemented, this will not affect any liquid staked assets that users obtained via the instant liquid staking feature. Instead, it will prevent you from using the LSM in the future without enabling it.

  • I plan to leverage the LSM in the future to liquid stake. If this gets implemented how do I do it? How long it will take?

    If you have any plans to leverage the LSM in future, you will probably be able to do so directly from the front-end of your LSD protocol of choice. The process will take 21 days, during which you will be able to earn staking rewards. After that, you can revisit your LSD provider ( or any other dApp leveraging the LSM) to liquid stake your assets.

3 Likes
2

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

4 Likes
3

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.

2 Likes
4

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

1 Like
5

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.

3 Likes
6

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!

1 Like
7

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

8

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.

5 Likes
9

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.

1 Like
10

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

2 Likes
11

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 will be discouraged from using it without an easy to locate UI for this functionality.

Now, I’m not saying that we should prioritize UX over security, but when the proposed solution creates such significant UX friction that it renders a core module functionally useless and doesn’t have a meaningful impact on security, it very clearly is not the right solution.

Default Opt-In Does Not Increase User Security

I disagree with this statement in particular.

As @zaki_iqlusion pointed out, this proposal doesn’t change the scammers’ workflow. It simply requires the scammer to enable the LSM, wait 21 days, and then steal the user’s funds. Meanwhile, the user continues to earn staking rewards as normal, and has little to no chance of discovering that the LSM re-enablement period is in process. What usually causes a staker to recognize their funds are in the process of being stolen is that they are no longer receiving staking rewards because their tokens are undelegating. This would not be the flow used by attackers were this proposal to pass.

Even if it was, the recourse that a user/staker has when their tokens are undelegating is minimal. It’s unlikely that the user in most cases would be aware of services like Cosmoshield (they list 150 users on their website), be willing to share their seed phrase with those services, and pay those services their standard fee for funds recovery. It’s also not guaranteed that Cosmoshield works - Cosmoshield runs a script that submits transactions and tries to beat the scammer. I’d push back strongly on the notion that this proposal would have a meaningful impact on the security of a user’s funds, whereas the impact on the LSM’s real and legitimate uses would be significant.

Staking Was Never Intended as a Security Mechanism for User Funds

This is one of the things that confuses me the most about this proposal. Somewhere along the way, a few people decided that staking should be considered a fallback mechanism for compromised user funds in the event that poor opsec or key management caused that user to allow their wallet to be compromised. This was never the intended usecase for staked tokens.

Staking is meant to enhance the security of the chain as a whole, not of the tokens of individual delegators. Reducing scam vectors should come from key management education as well as better warnings and frontend tooling that adds friction to interacting with malicious links. Other mechanisms can be put in place that would also help with this problem, for example, engaging a third party like Blockaid to protect against malicious signatures at the wallet or chain level (as dYdX and Osmosis have done)

This proposal distracts from the risk vectors that really matter and scapegoats one of the core modules that makes the Cosmos Hub unique. This is not a long-term solution to the problem, but it does have a very meaningful long-term impact on ATOM holders and the UX surrounding liquid staking.

2 Likes
12

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…

1 Like
13

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 proposals that do not have at least one non-NWV vote from an active set validator. This will make it so that legitimate proposals will be hidden until they get the attention of a validator, but it should work to hide all spam, and if a validator votes non-NWV on a spam proposal so that it gets shown they can be named and shamed.

2 Likes
14

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 things must be abandoned.

15

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 and if the there are links from not verified sites, community and especially validators will have enough time to NWV it and warn in the comments before that cooldown expires.

Also i noticed that, at least for Keplr i didnt pay attention to other wallets, it takes time, couple hours i think, to display how the voting goes thus creates some eclipse on how voting is going.
If people see right away that NWV votes start to flow in they will take a moment to decide whether to click the link or not but that if my idea for the cooldown is rejected.

1 Like
16

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 not being re-enabled again.

Thank you.

Regards,
arlai

2 Likes
17

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:

I fully disagree with this. While there is a UX trade-off to making the LSM opt-in by default, the module still eliminates the opportunity cost to liquid stake as staking rewards continue to accrue during the enabling period. Which is the main objective of the instant liquid staking feature. Therefore, I think calling an opt-in by default LSM unusable is inaccurate.

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.

Potential users will deploy their staked assets to liquid staking because they are interested in the use cases of the product and not because it’s easy.

It’s also worth noting that enabling is a one-time action for potential LSM users and not something that they have to do every time they want to deploy staked assets.

Interaction Friction:

The absence of a canonical front-end or a tool to disable/ enable the LSM is indeed a problem. But my opinion as to why it is a problem are different:

How is it that “forcing potential users to interact with an unknown UI to enable the LSM” is an interaction friction. But “forcing users to interact with an unknown UI to disable the LSM” is not?

If anyone should be forced to take additional actions when using the LSM, it should be potential users and not the ones that want to disable it.

I also do not think that the proposed solution creates UX friction in this sense, but actually improves it. With an opt-in by default, potential users won’t have to use unknown UIs to enable the LSM. Instead they will be doing it from the UI of the dApp they are looking to use.

This is because acquisition of potential users of the LSM happens at the dApp level. Which is why it’s in the interest of any dApp seeking to leverage the LSM to implement enabling the LSM to their UIs, just like LSD providers do with redelegating and tokenizing shares.

This way potential users won’t be discouraged as any additional trust assumptions that might cause UX friction are eliminated ( users will be trusting the same dApps that they trust to ‘tokenize their shares’ to also enable the LSM for them).

Default Opt-In Does Not Increase User Security:

No longer receiving staking rewards isn’t the only way users find out that they’re compromised. It could also be the redelegation/ tokenize share transaction. Either way, users with compromised wallets and stolen funds won’t blame the LSM in the case of an opt-in design even if it was used by the attacker. This is because no matter the workflow, the period is still the same: 21 days ( what every staker knows). Unlike the current design which has fast tracked the workflow of attackers from 21 days to a few seconds.

The likelihood of recovering in-the-process-of-being-stolen assets is less relevant in my opinion. My rationale here is that automatically assuming that all native stakers are aware and accept the risks of an enabled LSM isn’t the right approach. Especially when the LSM’s main goal is to regulate liquid staking.

18

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.

19

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 asset in the portfolio.

One might argue that these users are accountable for their losses and that it shouldn’t be our collective responsibility to bear the consequences of introducing the LSM, asserting that making it opt-in could deter DeFi adoption. We strongly oppose this perspective. Thus far, LSM adoption has been relatively slow, with one possible explanation being the widespread ignorance surrounding its existence and capabilities. To us, this presents a precarious situation. Hence, we’ve opted to support a preemptive approach until education on the LSM’s capabilities offsets the prevalent ignorance regarding its advantages and risks. For context, we’ve undertaken a similar initiative concerning authz transactions: Authz Module: Education on the Risks is Needed.

The rationale behind our support for an opt-in mechanism for the LSM is clear-cut. It offers a net and immediate protection to all ATOM users, with minimal detriment to DeFi. To mitigate any adverse effects on LSTs adoption, we propose:

  • Introducing a soft opt-in with a reduced activation period to a few days (48 hours, at least).
  • and/or set a time-cap to 20% of user stake accepted within the LSM for each period (48 hours minimum recommended here as well).

We sincerely hope that the community will listen to this call and act accordingly. We should not accept false statements and let them blur rational judgement. We are open to debate openly about the technical details but the truth must be told first, being direct actors in multiple leak recoveries we hope that our statement will shed light on what is factual and what is not.

1 Like
20

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 LSTs just know you can instantly convert your staked ATOM to stATOM, stkATOM, or qATOM. That’s the product that they care about. The entire messaging around “instantly converting to [ATOM LST]” is no longer true with this proposal.

It’s not an interaction friction because interaction with the LSM isn’t required to stake assets normally, which is what the bulk of people wanting to disable the LSM are doing. If you have staked assets, you are required to interact with the LSM to make them instantly liquid. There’s a userbase that wants to do this, and this proposal would alienate the vast majority of them. Whereas with an opt-out, this could be easily solved at the wallet level with a simple button.

This doesn’t make sense. The LSM is just one part of a larger product suite offered by the Hub. Many of the features and functions of the Cosmos Hub are not used by everyday users (governance, staking, validator creation, etc). Should we disable all modules for users by default just in case there’s a feature people don’t want to use? If we disabled all bank sends by default, scammers wouldn’t be able to send funds anywhere. Why not make all ATOM holders wait 21 days to send tokens anywhere by default?

While obviously an extreme example, I think it illustrates the point that shutting down a module comes with a tradeoff of usability of the product. Disabling bank sends for all users for 21 days would obviously make the product extremely unattractive for the bulk of users. What’s being proposed here is just a less impactful version of the same thing.

Yes, this is true, but in reality the user (who, remember, doesn’t know enough about blockchain to know not to input their seed phrase on a defi website), would have to know how to use a block explorer, have the good fortune to be looking at it during the 21 day period, see the transaction, and be able to recognize the transaction for what it is. The overwhelming majority of the time this would not happen.

If you’ve only done appx 12 of these in as many months, doesn’t that kind of prove the point that use of these services is not widespread enough to justify bricking a module?

I suppose there’s an argument to be made that even one malicious link causing users to lose funds via the LSM is too many (i.e., your “users shouldn’t be held accountable for their own losses” point). But if that’s the case, should we also eliminate governance so that these links shouldn’t be posted in the first place? Should we eliminate the wallets and other DeFi UIs that allow people to interact with links to completely eliminate the chances of anyone compromising their wallet?

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.