LSM removal and replacement: A possible plan

LSM removal and possible replacement plan The Liquidity Staking Module (LSM) was added as part of Gaia v12 in August 2023. Recent investigations have pointed to evidence that the LSM was written by North Korean agents. While it seems large parts of the LSM were rewritten afterwards, Informal does have concerns about the LSM remaining on the Cosmos Hub. The Cosmos Hub team at Informal Team has maintained the Gaia repository since before the introduction of the LSM, and we have contributed to resolving a security issue earlier this year. During our time maintaining the LSM and working on the Hydro protocol use case of it, we have also felt some pain points due to the high maintenance burden of the LSM implementation. The purpose of this post is to examine them, explore what a removal of the LSM could look like, and suggest an alternative restaking framework that could replace it. This is also in the spirit of recent discussions around restaking on the forum . The LSM status Use case The LSM brought new capabilities for developers and users: • Improved UX for liquid staking: The latency for entering a liquid staked position is removed, since users don’t have to un-stake…

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

Wow. Super interesting. The only thing that got my spidey senses tingling was the possible use of multi sigs. Seems like the whole industry is trying to phase out multi sigs for a better alternative, no?

That’s a good point. That sentence regarding multisig was just meant to illustrate that the framework itself is flexible in terms of how slashes/rewards are authorized and wouldn’t proscribe anything specific. Users ultimately have the choice of what services to opt into, so they aren’t subjected to slashing conditions that they haven’t agreed to beforehand, e.g. if a service is using a multisig to authorize slashes, individual users can decide that specific service doesn’t fit their preferences and not opt into it.

I’m pretty aligned with this roadmap.

The plan was always to modernize the staking module and drop the LSM after the cosmos sdk stabilized.

I would add a queue based unbonding so that users would in general get shorter unbonding periods but if there is a large amount of unbonding then it extends unbonding.

Basically unbonding time should be in a PID loop.

zaki_iqlusion:

I would add a queue based unbonding so that users would in general get shorter unbonding periods but if there is a large amount of unbonding then it extends unbonding.

Flawed again. Who can explain the game theoretic flaw of this proposal?

Could you answer if you told ANYONE about you hiring NK devs? As long as you don’t answer this question that is in the room since more than a week, you’re not trustworthy, and your credibility is zero…

Edit: it actually is and stays zero.

Instead of further advising how things should be done, follow informals and ICF example and write a statement about what happened.

Shorter unbondings (or immediate liquidation of staked atoms) goes against the base idea of staking/securing the network. Ding ding ding.

Seems like the only winners here are OtterSec and Zellic. What a waste of money and time. This junk should be stripped out asap.

Regarding the new restaking feature: The ability to do conditional slashing on the hub and let stakers add risk where they want opens new doors and new use cases to Atom, the typical example here is therefore hydro with the ability to block Atom stakers for several months in order to vote and obtain rewards for the price risks and the efforts provided but again it’s just an example, another possibility would be to form a contract with another chain outside of ICS to lend it collateral in contracts requiring guarantees. My only concern is in the possibility or not to condition the way in which one can slash atoms (burning or changing owner ), typically is it possible for a contract that has slashed capital to recover the slashed Atoms by the conditions or will they simply be burned? Regarding the removal of the LSM: This new feature would completely destroy the interest of LSM and therefore its removal seems to be the best option, however the switch between these two models should not be abrupt, as explained above this new restaking function allows for wider utility cases than LSM today, I think LSM can work in parallel with this new model for liquid staking until its…

Excerpt (1192 of 1676 characters). Read the whole post on the forum ↗

Given enough eyeballs, all bugs are shallow. Do not trust, verify. Another audit won’t save us.

With the unfortunate absence of a response from the assumed, frontfacing representative of Cosmos, @zaki_iqlusion, it is agreed that another audit would be minimally effective RE immediate security needs.

1 - 2 months time should be ample enough for current LSM users to revert their assets back to native. In respect to these users, LSM can fully live, and thrive, completely separate from the Hub.

Removing the LSM, as @jacobgadikian proposed prior, effective immediately, is favored.

Some thoughts : Restaking presents risks for Atom capital. Allowing stakers to take risks may be interesting, but it reduces the guarantee offered to consumer chains, which are supposed to be secured by the Atom stake. Similarly, a validator securing ten chains is potentially less reliable than a validator focusing on two chains with the same stake. Traditionally, validators are seen as service providers for consumer chains using ICS . However, the PSS model, especially with opt-in, requires few validators, which could leave some validators without a consumer chain and therefore without a business. Given this, it is interesting to ask if restaking could also become a business opportunity for validators? To minimize the risks related to restaking for consumer chains, validators could be allowed to decide whether or not they want to enable restaking for specific contracts, thus offering stakers new slashing conditions. For example, if a restaking contract offers a higher APR with additional risk, validators could decide whether or not to allow access to this contract for their delegators. Consumer chains that want high security could thus avoid validators involved in risky…

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

Interesting idea, thanks for thinking so deeply about this!

My first thought is with your suggestion, I would rather see the decision be made per-delegator - delegating to a specific validator shouldn’t make you unable to opt-in to a specific restaking service. Instead, restaking services could reject individual stakers whose stake is already over-leveraged. I don’t think there’s a reason to tie this too closely to validators (e.g. delegators could even delegate to a different validator on each consumer chain, in principle).

There’s research like StakeSure that introduces market-based mechanisms to determine the level of security needed for blockchains, and I think similar mechanisms could be applicable in this framework, too, to make sure each service gets the right level of stake and nothing is overleveraged.

The reason why I think that validators have a role to play in authorizing or not certain restaking contracts discretionarily is simple, some chains will not want delegators to distort their risk management when calculating economic security. Restaking by being partially isolated makes it easier for consumers chains to choose validators, the less they are exposed to restaking the less risk there is. In this way validators can choose which services they want to offer, delegators will choose their validators according to the risks they want to take and the market will balance out. Now indeed in the case of Hydro it does not necessarily make sense given that there is no risk of slashing. Also it is true that it is necessary to calculate what the real risks of “restaking” are, maybe my idea does not make sense compared to the risks taken by restaking. Thanks for the feedback and the shared paper!