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

[JohnMontagu]

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 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:

@RoboMcGobo

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.

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.

@RoboMcGobo

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.

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.