# LST support on Osmosis - a multistep plan
**URL:** https://forum.osmosis.zone/t/lst-support-on-osmosis-a-multistep-plan/2978
**Category:** General
**Created:** [July 17, 2024, 10:24am UTC](https://forum.osmosis.zone/t/lst-support-on-osmosis-a-multistep-plan/2978 "2024-07-17T10:24:16Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@JohnnyWyles](https://forum.osmosis.zone/u/JohnnyWyles)
#### Post date: [July 17, 2024, 10:24am UTC](https://forum.osmosis.zone/t/lst-support-on-osmosis-a-multistep-plan/2978/1 "2024-07-17T10:24:16Z")
Osmosis has historically used the community pool as a method of supporting the peg of OSMO based Liquid Staking Tokens (LSTs).
## A Brief History:
Initial backing of LSTs by the community pool was requested by Stride in September 2023:
> [@Deploy 20M OSMO to the stOSMO Pool](https://forum.osmosis.zone/t/deploy-20m-osmo-to-the-stosmo-pool/380):
>
> Summary This proposal aims to deploy 20M OSMO to the [stOSMO/OSMO stableswap pool](https://app.osmosis.zone/pool/833) (#833). Doing so would eliminate the need to spend internal OSMO incentives for stOSMO liquidity, reducing OSMO emissions. Furthermore, this would create deep stOSMO liquidity, enabling Mars to safely approve stOSMO as collateral. The OSMO would be sent to a DAODAO multisig controlled by trusted community members. The multisig would provide the OSMO as liquidity, and then transfer the resultant LP tokens to the Os…
This was expanded as part of the SAIL proposal to include an addition 2.5m OSMO for ampOSMO and bOSMO support.
> [@Sail With the Whale V2: SAIL DAO (Updated)](https://forum.osmosis.zone/t/sail-with-the-whale-v2-sail-dao-updated/1041):
>
> The Previous proposal #694 “Sail With the Whale” requested deployment of 5 mil OSMO to seed 2 LST pools on White Whale DEX deployed on Osmosis chain. On top of the deployment of WW DEX onto Osmosis, other obligations from the Whale side included integration of OSMO LST’s into Migaloo ecosystem projects as well as further SC deployments and liquidity pools on Osmosis, as is consistent with the “Sail With The Whale” program. Based on community feedback, we have given the first edition of the prop…
Half of the 20M OSMO provided to the stOSMO stableswap was migrated to a static concentrated liquidity position which increased liquidity efficiency by 2.5x as well as exiting its portion of stOSMO over 4 months and expanding the LST support to stkOSMO and qOSMO.
> [@Re-evaluation of Liquid Staked OSMO held by the Community Pool](https://forum.osmosis.zone/t/re-evaluation-of-liquid-staked-osmo-held-by-the-community-pool/2654):
>
> This set of three proposals would diversify the OSMO currently used to support stOSMO liquidity in the community pool by: Withdrawing 50% of liquidity from the stOSMO/OSMO Stableswap pool Redeploying this into a more efficient stOSMO/OSMO Supercharged position Using the OSMO saved from this capital efficiency improvement to establish Supercharged positions of qOSMO and stkOSMO. This proposal approves the withdrawal and redeployment of stOSMO/OSMO liquidity as well as performing the community …
The last proposal was a 200k OSMO trial of Locust vaults which are automated vaults with a specialised type for LST liquidity provision and maintenance.
> [@Deployment of stOSMO liquidity from stableswap into Locust vault](https://forum.osmosis.zone/t/deployment-of-stosmo-liquidity-from-stableswap-into-locust-vault/2841):
>
> This proposal follows on from [Proposal 769](https://daodao.zone/dao/osmosis/proposals/769) to re-evaluate the stOSMO/OSMO liquidity held by the Osmosis Community Pool. This proposal would diversify an additional 200k Stableswap stOSMO/OSMO liquidity as a trial deployment into a [Locust vault](https://trade.margined.io/vaults). About Locust Locust is a market making and position management tool specifically designed for Concentrated Liquidity (CL) pools. In CL pools liquidity is often provided at an inefficient ranges. This is largely due to the difficulty of active managemen…
## Current State:
Positions currently held by the community pool are:
- Stableswap of 4.85m OSMO & 4.11m stOSMO (Equivalent Total OSMO: 9.7m)
- Concentrated static position of 4.64m OSMO & 2.95m stOSMO (Equivalent Total OSMO: 8.3m)
- Concentrated static position of 842k OSMO & 219k stkOSMO (Equivalent Total OSMO: 1.07m)
- Concentrated static position of 931k OSMO & 0 qOSMO (Out of range) (Equivalent Total OSMO: 931k)
- Locust stOSMO/OSMO position of 131k OSMO & 57k stOSMO (Equivalent Total OSMO:
202k)
In addition, the liquidity provided to SAIL DAO to back ampOSMO and bOSMO is:
- 635k OSMO & 576k ampOSMO (Equivalent Total OSMO: 1.27m)
- 630k OSMO & 615k bOSMO (Equivalent Total OSMO: 1.26m)
This can be represented in two ways:
_Chart 1: Protocol provided liquidity exposure to assets_
_Chart 2: OSMO backing of LSTs_
## Targets
### 1. Minimal OSMO staked using Protocol Liquidity
Chart 1 started at a 50/50 ratio between OSMO and non-OSMO due to deployment into stableswap and WhiteWhale pools.
50/50 deployment requires the community pool to be holding the LST and so staking despite not being able to vote.
This is the complaint raised by multiple contributors that the community pool should not be able to stake or dilute existing stakers and so should be minimized.
This will never be entirely eliminated as long as there is an LST support methodology as the protocol will always be buying the LST under the redemption rate, and with static positions, will need to maintain liquidity above the redemption rate in order to remain in range for a period.
The first step’s impact of migrating liquidity from the stableswap to the concentrated liquidity pool can already be seen as the concentrated liquidity share of assets has skewed from the 33% OSMO, 66% stOSMO position set 2 months ago in [DAO DAO](https://daodao.zone/dao/osmosis/proposals/769) to a 55% OSMO, 45% stOSMO position, reducing the community pool’s holding of stOSMO.
### 2. Diversity of OSMO LSTs
When there is free choice, most distributions tend to fall into an 80/20 dominance by a single player. LSTs are particularly prone to this since the successful LST will have deeper liquidity and more markets for it to be used in.
Osmosis should care about a single LST provider dominating the space since, without any method of capping exposure to this, there becomes an inherent bias to the stake towards an LST monopoly and, eventually, potential security reliance on the LST provider.
[Re-evaluation of Liquid Staked OSMO held by the Community Pool](https://forum.osmosis.zone/t/re-evaluation-of-liquid-staked-osmo-held-by-the-community-pool/2654) and part of [Sail With the Whale V2: SAIL DAO (Updated)](https://forum.osmosis.zone/t/sail-with-the-whale-v2-sail-dao-updated/1041) were the mechanisms by which alternative LSTs were attempted to be bootstrapped as viable alternatives.
Chart 2 shows that this has been relatively successful, as the 80/20 Pareto split is being pushed backwards. This is currently reverting as the static stOSMO concentrated position turns into greater numbers of backing OSMO however.
### 3. Resilient Pegs for OSMO LSTs
While resiliency is not defined here, a LST’s peg to its redemption rate needs to be reliably constant for it to perform its task as a true liquid staking asset.
In normal trading, this requires minimal liquidity to accomplish; the reliability is more relevant during periods of heavy off-risking or liquidations.
stOSMO performed very well during the recent market crash with only a 0.5% depeg occurring.
Arbitrage is the mechanism for restoring these pegs with the return for arbitrageurs being the percentage depeg vs redemption rate, minus the swap fee, over the LST unbonding period (17 days).
As this is a single asset exposure to OSMO it often finds equilibrium at the staking APR.
i.e. (10.5% /365)\*17 + 0.05% Swap = 0.54% depeg.
The further 0.5% depeg that occurred on this day lead to a doubling of the OSMO staking APR for market participants performing this task.
The resilience required can, therefore, be estimated as the reward rate for liquidity to perform this action. Around 4x Staking APR would give a depeg required of 2% - which informs the range at which liquidity should be provided.
## Next steps
Each step shows the link to the above targets by labelling of 1, 2 and 3.
(1) Minimal OSMO staked using Protocol Liquidity
(2) Diversity of OSMO LSTs
(3) Resilient Pegs for OSMO LSTs
1. Evaluate success of Locust vaults deployed in [Proposal 798](https://daodao.zone/dao/osmosis/proposals/798) (1, 3) **Early August**
2. If Locust data looks good then proceed with wider deployment. If not then use New Static positions (2, 3) **Early August**
3. Re-evaluate the distribution of OSMO backing between all five LSTs based on usage. (1, 2, 3) **Mid August**
4. Trial of Slow Burn Arbitrage vault (1, 2, 3) **Late August**
5. Potential Expansion of Slow Burn Arbitrage Vault. **September**
Please leave any feedback in this thread. I hope that this plan will go a long way towards addressing common issues that the community has raised with the current method of supporting LSTs on Osmosis whilst also not removing the benefits we have right now.
---
### Author:  [@ValarDragon](https://forum.osmosis.zone/u/ValarDragon)
#### Post date: [July 17, 2024, 10:38am UTC](https://forum.osmosis.zone/t/lst-support-on-osmosis-a-multistep-plan/2978/2 "2024-07-17T10:38:26Z")
Great writeup of the history here! I strongly agree with the targets here.
BTW, should osmo governance also push for the unbonding periods to be tighter? The chain has 14 days, stride has a 3 day buffer on top, but the buffer on top should actually be 2 days with only one staking address, and you can use two addresses to make it 1 day.
To clarify, the “burn” in slow burn does not refer to burning any tokens, correct? Its just that they have some osmo, and effectively “DCA” into whoever is the most under-water, and start unbonding, right?
---
### Author:  [@JohnnyWyles](https://forum.osmosis.zone/u/JohnnyWyles)
#### Post date: [July 17, 2024, 11:28am UTC](https://forum.osmosis.zone/t/lst-support-on-osmosis-a-multistep-plan/2978/3 "2024-07-17T11:28:19Z")
> BTW, should osmo governance also push for the unbonding periods to be tighter? The chain has 14 days, stride has a 3 day buffer on top, but the buffer on top should actually be 2 days with only one staking address, and you can use two addresses to make it 1 day.
Using 17 days as an estimate here - the Stride unstaking trigger seems to be periodic between 15 and 17 but the limitation is indeed based on this being one address unstaking at once. stkOSMO, qOSMO and stOSMO all seem to follow the +3 rule though.
Agree that this should be shorter if possible!
> To clarify, the “burn” in slow burn does not refer to burning any tokens, correct? Its just that they have some osmo, and effectively “DCA” into whoever is the most under-water, and start unbonding, right?
Yes, it’s just a turn of phrase there relating to the entire vault likely not being used at once.
Enter a vault with OSMO, a portion of that is then used to buy the most depegged LST. The greater the depeg the more gets purchased. This then unbonds and results in a higher amount of OSMO than started with.
i.e. deposit 100 OSMO, potentially buy 80.6 stOSMO at 1.24 when redemption rate is 1.25, auto-unbond, end up with 100.8 OSMO 17 days later, repeat = 17.2% APR / 18.7 APY
Would result in all LSTs integrated having roughly the same depeg percentage over time.
Eris does have one for bOSMO and ampOSMO only at the moment: [Eris Protocol](https://www.erisprotocol.com/osmosis/arb-vault)
As a bonus, if LSTs pushed the unbonding time down to 14 days there would likely be a closer peg to redemption.
If Osmosis governance dropped the unbonding time it would get even closer.
---
### Author:  [@faddat](https://forum.osmosis.zone/u/faddat)
#### Post date: [July 18, 2024, 8:04am UTC](https://forum.osmosis.zone/t/lst-support-on-osmosis-a-multistep-plan/2978/4 "2024-07-18T08:04:11Z")
I just wanted to post that I have read through this and find it very interesting.
I may have additional thoughts, which I would post later, when they come to me 🙂
---
### Author:  [@LeonoorsCryptoman](https://forum.osmosis.zone/u/LeonoorsCryptoman)
#### Post date: [July 18, 2024, 8:11pm UTC](https://forum.osmosis.zone/t/lst-support-on-osmosis-a-multistep-plan/2978/5 "2024-07-18T20:11:56Z")
In the first read I agree with this.
In essence the exposure of Osmosis-protocol funds should be minimal towards LST-providers, since it invokes the risk of preference as well as reliance on just a few (if not just one) protocol for providing the service. I think Osmosis fares better with being able to rely on multiple competing providers, which are always pushed to perform better and better in terms of innovation and value adding to Osmosis as a chain and as a project.