Deploy Protocol Owned Liquidity of stSTARS/STARS

The Osmosis community pool currently possesses several non-OSMO assets that can generate further yield for the protocol and deepen useful markets on Osmosis.

Currently, these include:

Assets received as part of proposals or subDAO agreements
1.09M AXL (~$1.1m)
6.3M STARS (~$290k)
35k AKT (~$104k)
5000 SCRT (~$2k)
250,000 UMEE (~$1.5k)

Increasing Stablecoin revenue from Taker fees
Currently totalling $265k in
214k USDC
30k USDT
19k axlUSDC
1.6k DAI

Increasing Volatile token revenue from Taker fees
13.5k ATOM (~$138k)
1.8k TIA (~$34k)
9.9 ETH (~$25k)

Custodied on Behalf of ION DAO, included for completeness
11.1k ION

This proposal is the first of a series that will propose utilizing these assets as Protocol Owned Liquidity to:

  • Protect the value of Protocol-owned assets against inflation.
  • Create new markets on Osmosis through bootstrapping the liquidity rather than incentive use
  • Reduce swap fees in existing routes, increasing Taker fee generation.

Proposal Text

This proposal would transfer the STARS in the Osmosis Community Pool to an intermediary Liquidity subDAO to be processed and returned to the Osmosis Community Pool as Protocol Owned Liquidity of stSTARS/STARS.


The Osmosis Community Pool owns 6,314,579.55 STARS, mainly from the loan repayment for the STARS Loan Swap (Proposal 99).

This STARS has been sitting unused in the community pool for the past two years, losing value to inflation on Stargaze.

This proposal aims to deploy this liquidity to maintain the value of the tokens against STARS inflation while fulfilling a useful function on Osmosis.


Liquidity will be deployed into a newly created stSTARS/STARS supercharged liquidity pool with a swap fee of 0.05% with ranges set as:

  • Lower position of 1.1, providing a wide position in the pool to enable the use of stSTARS as collateral in applications.
  • Upper position of 1.62, the projected redemption rate in 1 year. This ensures that some of the STARS position is staked to lower the impact of inflation on the community pool holdings and ensure that the position remains valid for a year.

Swap fees for deploying protocol liquidity will err on the low side compared to pools currently favored by regular liquidity providers to make the wider, static range more competitive as well as ensure that a higher proportion of trading fees are collected in the form of Taker Fees rather than by the position itself.

This position requires around 40% of the STARS to be converted to stSTARS. This will be performed by a combination of purchase on Osmosis, where this receives more than the current peg, and direct liquid staking on Stride.

This liquidity position will then have the ownership transferred back to the community pool.

Liquidity subDAO

This is a 4/6 reusable multi-sig and is comprised of:

Target On-Chain Date: 14th January 2024


Love that these are separate pools so we aren’t directly taking rewards from existing LPs, 1 market driven LP, 1 pure trading focused LP

Will we need OSMO to create this new pool?


Definitely supportive of this! One thought that I do have though is that maybe we could tighten this range slightly on the lower bound.

If you look at the trading history on the current pool you can see that the pool has never depegged by more than 20% (and even that was an extreme situation).

Currently, stSTARS is off peg by 0.08 STARS. The peg is currently 1 : 1.42. Benchmarking against the one-off 20% depeg event, we could feasibly make the lower bound 1.1 instead of 1 (allowing for a 23% depeg). This would allow for the community pool to hold a larger portion of yield bearing assets and collect more fees, which directly advances the goals of this initiative. The lower fees on this pool also make arbing the peg more profitable, which should help with peg defense a bit more.

All of that being said, I think that a lower bound of 1 is pretty close and would be supportive of this either way! We might just be able to do a bit better without too much added risk.


I was definitely debating this question before putting up the proposal.
Future years will almost certainly move the position along by increasing both lower and upper ticks.

1.1 seems totally reasonable to me, I was considering 1.2 and that large depeg event put me off. Although having deeper and concentrated liquidity would also minimise the chances of a depeg event. Liquidity has vastly improved since that event even - although stSTARS has minimal usage compared to stATOM and stOSMO.

I’ll edit the proposal to reflect this change.


Technically the protocol liquidity pool will also be freely joinable by LPers and be listed on the frontend.

stSTARS/STARS Classic pool has 0.3% fees and $1m liquidity
stSTARS/STARS CL pool has 0.2% fees but only $2.5k in liquidity. This was managing to get a highly disproportionate amount of the swaps through stSTARS until recently, when the depeg sent the positions in that pool out of range.
Side note: How there is no publicly available repeg bots for Stride amazes me. The going rate for depositing STARS and redeeming it is about 150% APR in the token itself right now, its just a slightly awkward flow.

Protocol liquidity in a 0.05% pool would be far more likely to take volume from both pools, but a more concentrated position in 0.2% would still get a lot of the volume.
More concentrated user positions in 0.05% would then be the best potential fee acquisition rate, but that relies on people swapping into and out of the asset frequently enough to beat the stSTARS APR for the STARS half. So would only be the case if stSTARS started to see heavy usage.

This pool will get made by the permissioned creation group, needs a little USDC but that can be provided outside of this proposal.

1 Like

In general ok with deploying these funds to be used. Which makes me wonder though; if we put the funds into a CL position, how can we adjust? That will be the responsibility of the DAO I guess? But would that not be hard to do because the ownership is transferred back to the CP?

And, are there any talks about automated adjustments of CL positions? Deploying CP funds into a CL position would greatly benefit from automated adjustments to have the position shift along a new peg where needed. Stride now has code for it, should we learn from that and see what is possible with our own protocol?

1 Like

We can transfer the position back to another multisig in order to change the position. The idea with these settings is that we shouldn’t need to adjust them for a year.

Using a vault for automated adjustments is great for optimisation, however what we need here is reliable width as well as depth so this protocol liquidity will form the backdrop for other positions.

By the time this needs adjusting then there should be multiple vault options to choose from, where we can even provide to a combination.

1 Like


So we can assess in about a year with respect to the performance and adjust accordingly.

Ah wow this is a huge upgrade then considering 2.5k is doing all the work rn