LST support on Osmosis - a multistep plan

[JohnnyWyles]

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

Summary This proposal aims to deploy 20M OSMO to the stOSMO/OSMO stableswap pool (#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)

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

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

This proposal follows on from Proposal 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. 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 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 and part of Sail With the Whale V2: SAIL DAO (Updated) 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 (1, 3) Early August

   • This trial has been in place for 2 weeks. Data is being collected to show whether the vaults are both skewing towards OSMO holding (early data suggests yes) (1) and the impact on liquidity efficiency. (3)

2. If Locust data looks good then proceed with wider deployment. If not then use New Static positions (2, 3) Early August

   • Migrate liquidity from stkOSMO and qOSMO concentrated positions to Locust Vaults/New Statics (2, 3)
   • Remove further liquidity from stOSMO/OSMO stableswap to increase stOSMO/OSMO Locust holding by 800k to 1M OSMO backing (3)
   • Establish smaller additional Locust vaults of bOSMO and ampOSMO (2)

3. Re-evaluate the distribution of OSMO backing between all five LSTs based on usage. (1, 2, 3) Mid August

   • Establish the actual OSMO backing required for LST expansion at this time. The current budget of 22.5M is likely too high. Return any excess to the community pool.
   • Assess the distribution of backing based on:
     • Minted supply without Protocol (Off-risking potential)
     • Collateral in use (Liquidation potential)
     • Typical volume (Adoption)
   • Remove all Protocol Liquidity from stOSMO/OSMO stableswap pool to move fully to Static CL and Vault based solutions.
     • Redeem stOSMO for OSMO as this side of liquidity has minimal purpose for Osmosis and dilutes stakers. (1)
     • The buy side is catered for by the Locust pools and the static concentrated liquidity position.

4. Trial of Slow Burn Arbitrage vault (1, 2, 3) Late August

   • A Slow Burn, multi-asset arbitrage vault is currently being developed for deployment. This allows the deposit of OSMO which is then used to automatically arbitrage a position in any of these LSTs back towards the redemption rate. (2,3)
   • This reduces the need for specific liquidity in any one LST since any depeg in one will be rapidly normalized to the same level across all LSTs. (2, 3)
   • Coupled with increased utilization of Locust vaults which minimize the liquidity needed to return to the redemption rate, this should provide deep liquidity over multiple blocks to all OSMO LSTs (2, 3), while only requiring OSMO liquidity to be provided by the protocol (1)
   • Shallow liquidity may cause depegs to occur over a single block, but as lending protocols should be using a TWAP to determine liquidations, minority LSTs should be far safer to adopt for collateral usage (2).

5. Potential Expansion of Slow Burn Arbitrage Vault. September

   • At this point the static stOSMO position set in Proposal 769 should be entirely OSMO and need to be reassigned.
   • If Slow Burn Arbitrage vault does not attract liquidity through exceeding the staking APR then utilize this to provide deep, LST agnostic, liquidity.
   • This deployment would also potentially cause a net reduction in the circulating supply of OSMO as each LST redemption would effectively return some OSMO to the community pool.
   • If this is not required then this should be redistributed according to Step 4.

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.

[ValarDragon]

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?

[JohnnyWyles]

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

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.

[faddat]

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

[LeonoorsCryptoman]

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.