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:
This was expanded as part of the SAIL proposal to include an addition 2.5m OSMO for ampOSMO and bOSMO support.
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.
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.
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
-
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)
-
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)
-
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.
-
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).
-
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.
