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 or utilize liquid ATOM to obtain LSTs.
- Unlock additional use cases for staked ATOM: The LSM allows utilizing staked ATOM as collateral in other protocols without having to give up on staking rewards, even outside of the LSM. For example, Hydro utilizes LSM-tokenized shares to allow users to receive staking rewards, while those users commit to longer lockups and in the future, potentially extra slashing risk.
Shortcomings
However, the LSM undeniably has severe shortcomings. The obvious one is that the current understanding is that North Korean agents have significantly contributed to its development, but there are also other technical aspects:
- The LSM is deeply integrated in the staking module instead of being a standalone module with a clear separation of concerns. This also means that the Cosmos Hub has needed to utilize a fork of the Cosmos SDK since its introduction.
- Amplifying the first point, the logic in the LSM is rather complex - for example, each separate tokenization produces a separate token denomination. It seems fair to assume that this point in particular has stopped the LSM from gaining significant traction outside of letting users “liquefy” their staked ATOM without a delay.
- Users that tokenize their delegation cannot participate in governance. On the one hand, this is reasonable (since holders of liquid ATOM can exit their position immediately, instead of having to wait for the un-bonding period to end before they can), but on the other hand, this again hurts the UX of using LSM-tokenized-delegations in use cases that want to keep the staked ATOM locked and under ownership of the user.
Essentially, today the LSM is merely used to a) tokenize an existing delegation, b) transfer the tokenized shares somewhere else, and then c) un-tokenize the shares to get back a native delegation. Accordingly, today there are about 8,000,000 ATOM liquid-staked (either held as LSM shares or staked by an Interchain Account); but only 5,000 ATOM are actually held as LSM shares (gaiad q staking total-liquid-staked vs gaiad q staking total-tokenize-share-assets).
For use cases like Hydro that are aiming to bring more utility to staked ATOM (in Hydros case, giving voters that lock their staked ATOM for a longer time voting power to determine the allocation of protocol-owned liquidity), this existing pattern is not a great fit:
- Users that tokenize their shares cannot vote in governance anymore.
- Users that tokenized their shares cannot redelegate easily. If the validator they delegated to becomes e.g. inactive, the tokenized shares have to be untokenized, then a redelegation has to be initialized, and once it is done the shares have to be tokenized again.
Essentially, the existing LSM is enough to enable use cases like LSTs, but use cases that don’t necessarily care about making the staked ATOM liquid, but instead care about utilizing staked ATOM for other purposes while having the ATOM remain locked are hard to build on top.
In the following, we briefly outline a pathway to how the LSM can be removed, followed by a suggestion for a new framework to replace the LSM if the community indeed decides to remove the existing implementation.
Removal
Removing the LSM likely involves significant work, and additional effort is necessary to de-risk and scope the process out fully. For a brief reminder, this is how the LSM operates today:
- For each time a user tokenized some delegation shares, there is a tokenization record stored in the Cosmos Hub store, and additionally the LSM shares are minted as liquid, tokenized representations of the delegation shares.
- For each LSM tokenization, there is a two-fold concept of ownership: The tokenization record has an owner (who can withdraw the rewards accrued by the tokenization record), while the underlying LSM shares may be held by completely different entities.
- When the LSM shares are untokenized and turned back into a native delegation, the tokens are removed from circulation, and the tokenization record is deleted.
- Currently, there are roughly 5,000 ATOM worth of outstanding tokenized shares.
Here is a brief sketch of the process of removing the LSM shares, as per our current understanding:
- When the Cosmos Hub community votes to remove the LSM, it will give the holders of LSM shares a grace period of 1-2 months during which they are expected to un-tokenize the LSM shares and turn them into native delegations.
- Once the grace period is over, the Cosmos Hub upgrades to remove the LSM. Importantly, tokenization records are removed from the store, and the outstanding LSM shares become useless (as they will not be reclaimable for native delegations anymore). For these removed tokenization records, the tokenized delegation is forcefully untokenized and transformed into a native delegation owned by the tokenization record owner at the time of the migration.
This plan would give every holder of LSM tokens time to un-tokenize their shares (which is an instant process with no waiting time) ; and for holders that don’t un-tokenize their shares and reclaim their native delegation, this solution still employs a strategy to attempt to restore their original delegation. Due to the dual-ownership concept present in the LSM that was briefly explained above, it seems that any migration solution will need to make a choice on what ownership to treat as intended. This solution strikes a fair balance.
A new framework
We are proposing a different framework that keeps the advantages of the LSM while mitigating the most severe problems. The idea is very close to the restaking primitives proposed by Eigenlayer and others. In short, users can:
- Subject their stake to extra conditions and slashing risks
- Get additional rights in return.
The Hydro use-case
Hydro is an instance of this generic framework:
- Users subject their stake to a prolonged lockup time (they lock their stake for an extra 1-12 months on top of the underlying unbonding time) and an extra slashing risk (e.g. users could be slashed if liquidity exports they voted for underperform).
- Users that lock in Hydro get voting power to determine the allocation of the Protocol-owned liquidity that projects bid on via Hydro, and they receive additional yield through tributes paid by the projects bidding for liquidity to voters that vote on their bids.
The ICS use-case
This general framework encompasses Interchain Security as a special case, with the key distinction that in Interchain Security, the principal actors participating are validators. Validators opting in to validate on a consumer chain subject themselves (and their delegators) to extra slashing and jailing conditions (if they accrue downtime on the consumer, or double sign, the validator will be jailed and/or slashed), but they also receive extra rights (the right to validate on the consumer chain and receive rewards issued by the consumer chain).
New uses cases
This illustrates exactly the difference to the existing restaking solution in Cosmos: the actors are individual voters, not validators. This framework enables essentially all use cases that restaking solutions like Eigenlayer enable, like relaying or oracles, but so much more elegantly than can be done by the existing ICS paradigm. It would also enable further use cases around governance, where governance can be more elegantly separated from block production than is the case today (for example, users could delegate to a certain validator for block production, but delegate their governance vote to a completely separate (potentially non-validator) entity, or could not delegate their governance vote at all).
Interface
This restaking framework offers just a few main functions:
- Creating a new restaking service: This creates a new responsibilities+rights service that users can then opt into. This specifies the conditions that users apply to their stake by opting in, the rights/rewards they get for doing so. Additionally, the service can provide assumptions on what other opportunities users can be opted in to with their stake. For example, a service might want to limit risk and not allow users to opt in to other services with the same stake that they are opted in to this service; or other services may not place any restrictions.
- Opting in/out: A user can opt into or out of a certain restaking service. Depending on the service, there may be additional conditions on opting in or out (e.g. there may be a waiting period before the opt-out takes effect).
- Slashing/Force-opting-out: A service can slash, or potentially forcefully opt-out, any user that is currently opted in on it, or is still unbonding from the service. Some services will place strict restrictions on slashing (say, slashing only when there is evidence of a double-sign involving the user or their delegated-to validator entity), while others can impose more subjective conditions (such as slashing if a user votes for a liquidity deployment that underperforms).
- Paying out rewards: A service can pay out rewards to (a subset of) users, e.g. according to a function on the amounts of the users stake.
The level of commitment behind slashing and paying out rewards can be decided on by each service individually. Services may utilize multisigs to authorize reward payments or slashes, while others might utilize smart contracts on the Cosmos Hub or Interchain Accounts controlled from another chain. In each case, empowering an account on the Cosmos Hub to perform these actions is good enough; just how that account is controlled differs from case-to-case.
There is also no need for a user to delegate to the same validator in different “restaking services”. For example, a user might want to delegate to Validator A in core Cosmos Hub PoS, but to Validator B on a consumer chain, and might want to delegate their voting power in Hydro to a completely separate non-validator entity.
In general, this framework would let the Cosmos Hub enable use cases for restaking outside of simply securing consumer chains, while avoiding the main shortcomings of the LSM.
This writeup purposefully doesn’t go into the implementation details, but the goal is to make only the absolutely necessary, minimal modifications to the mainline Cosmos SDK staking module, and implement the components to offer the unified, convenient interface separately (potentially as CosmWasm smart contracts, or at least as a separate Cosmos SDK module).
Next steps
Informal is coordinating two audits by two separate security firms as a short term response to the news of the involvement of North Korean developers in the LSM development.
The community may decide how to proceed with the existing implementation, but for the technical reasons outlined earlier, our recommendation is to remove the LSM and replace it with an implementation of the framework described above.
It should be noted that the work involved in the removal & replacement is quite significant and would most likely take multiple months. Informal Systems has decided to not lead a funding proposal in 2025 so at this stage this post is primarily an effort to bring up a potential solution to the attention of the community and receive feedback on the idea.
: