Signaling Proposal to Update the Incentives Program

[HathorNodes]

Purpose

This proposal signals community consent to migrate LP incentives to use an optimization algorithm. The Osmosis Grants Program partnered with Chaos Labs and Hathor Nodes to research, develop, and implement a new method of distributing internal incentives to LPs. This is a continuation from the original proposal with community feedback applied.

The algorithm and its methodology can be viewed here. The algorithm was developed based on research that has been conducted over the last few months. Updates made since the last post can be viewed here. The research is not final, and the paper outlines future research for fine tuning the algorithm over the next few months.

The algorithm focuses on creating smart incentives. Its goal is to provide the minimum number of incentives required to maintain healthy liquidity levels. This means some LPs can have their incentives increased, while others are decreased. An example of this is the increase signaled in LPs for the USDC/OSMO LP compared to the reduction signaled for the ATOM/OSMO LP. An LP’s incentives could increase one month and then decrease or remain the same the next. The goal is streamlining the incentives process while keeping its cost to the protocol low.

Updates Since Last Time

This section will provide a high level overview of changes made to the model since the last post.

Constraints Refactoring

Originally, the optimization process was focused on swap data (i.e. swaps occurring in each LP). The community requested we broaden the process to include liquidity needs that are not related to trading volume and slippage. After some refactoring, we are now able to accommodate constraints of any kind.

Stableswap LPs

Originally, Stableswap LPs were set to receive 4% of incentives designated for LPs. This process has been updated to reflect the process currently used.

Competitive Slippage Levels

The community requested we lower the maximum slippage levels in Balancer Pools to ensure trading on Osmosis remains competitive w/ other dExes. We’ve reduced the maximum slippage levels from 1% for retail swaps and 10% for whale swaps to 0.25% and 2.5% respectively. These levels can be adjusted as needed.

TWAP Oracle Manipulation Resistance

As Osmosis grows, it begins to host dApps that rely on its TWAP Oracle pricing. TWAP Oracles can be targeted for manipulation by malicious actors. To ensure that builders on Osmosis can comfortably use our oracles, we’ve added a liquidity constraint for a few pools:

• Pool 1: ATOM/OSMO
• Pool 678: USDC/OSMO
• Pool 704: axlWETH/OSMO
• Pool 712: axlWBTC/OSMO

This constraint calculates the minimum liquidity required to hinder attacks on these LPs TWAP Oracles.

What are the next steps and longer term plan if this proposal is accepted?

The plan for phase 2, the immediate next steps, can be adjusted based on community input in this thread! Here are our thoughts at the moment.

Immediate Next Steps (1-2 months)

• Monitor LP efficiency
• Volume discovery and increase effectiveness of LP bootstrapping

Post Calibration Period

• Working group to monitor and provide adjustment recommendations
• Supercharged Liquidity Incentives

Part of the goal of this discussion is to open the floor to the community for any questions you might have. We’ll be answering questions in this post over the next week or two before putting the proposal on chain.

Discussion Topics

To help facilitate the discussion, we’ve selected a few topics that we’d like community input on.

1. External Incentives

We received mixed feedback on if external incentive matching should be automated or not. Would love to poll the community on this again.

2. Immediate Next Steps/Future Research Topics

We’ve outlined some areas of further research in the original paper. If the community has anything they’d like to see researched or fleshed out, feel free to leave suggestions! Glad to discuss those topics and even shift priorities around if there’s anything of particular interest to the collective community!

Future topics of further research:

• Inactive Liquidity: Some LPers are now inactive users. In theory, if they should never return, the incentives APR is irrelevant to them. If they’re still unbonded, they will still receive a share of these rewards though. Some additional research into accounting for them could be helpful in finer-tuning incentive numbers.

• Monitoring LP Efficiency: Having a central location to monitor the Volume/Liquidity and Liquidity/Incentive ratios of LPs would be helpful for both the incentives working group and the broader community. This data can also be used for setting target TVLs as an alternative to the current methodology.

• Volume Discovery: Liquidity in an LP draws volume, but there is a diminishing return to this relationship. When bootstrapping LPs, having a fine tuned algorithm for shifting the target TVL for the first few months -instead of a constant default- could help maximize the volume/liquidity ratio of newer LPs.

• Stableswap Liquidity Optimization: Applying the broader concepts of this process to our core stableswap LPs. The LPs are relatively new so a bootstrapping period is needed regardless so this can wait a few months.

3. Incentivized Pools Selection

The scope of this grant was focused on how to provide incentives to LPs that have been selected by the community. Is there interest in having this group research and present any possible metrics/indicators that an LP is in need of incentives?

4. Recent Tokenomic Changes

With the recent set of tokenomic changes, inflation and LP rewards have been reduced. A month has passed since these changes and so this program would proceed as planned if passed. Alternatively, if the community feels that incentives have been reduced enough, we can run the optimization program in maintenance mode. This would set the target liquidity level of healthy LPs equal to their current liquidity level and then simply increase/decrease incentives based on their GAMM velocity.

Next Steps

We will answer questions on this post until next Wednesday/Thursday. Then a proposal will be made on chain. If this proposal passes, then the incentives will shift to being run by this incentives program. Chaos Labs and Hathor Nodes will monitor incentives and liquidity levels of pools and put up future incentive adjustment programs. Public meetings will be held twice a month to discuss the state of incentives. The first incentives change would not occur until after the first working group meeting (Mid August if all goes well).

Acknowledgements

Last but not least, we’d like to once again acknowledge and thank our data providers and earlier reviewers. Their infrastructure and assistance has been invaluable to this process!

Data Providers:

Flipside Crypto
Yieldmos
Allthatnode

V1 Early Reviewers:

RoboMcGobo
JohnnyWyles
EmperorOsmo
Connor | Flipside
Soi2studio

It’s been a pleasure working on the incentives program these last few months, and we look forward to hearing from the community!

[LeonoorsCryptoman]

I am slightly lost on whether the part to be put on chain is finished or not. It reads like it is ready to be deployed, but in the first part of the text you state; “The research is not final, and the paper outlines future research for fine tuning the algorithm over the next few months.” which kinda feels like there is still a lot to be done an optimized before we can put this into action.

Some questions / comments which are in my mind;

• we are now running into the phase where supercharged liquidity pools will be created. Do you think they will mess with the program? Or is the current program already kind of prepared for that?
• why would we need to change something on incentive matching? It is for me exactly what it says; incentive matching. If we would create some kind of calculation which would appreciate an externally incentivized $ from project A different than an externally incentivized $ from project B… that would be weird and hard to explain. Imo we should work to simplify Osmosis for the average user, not make it more complicated.
• would it be possible to somehow also simulate how swap fees apply to the liquidity needed? I mean, there are exchanges (DEX / CEX) out there with lower fees than we apply. With the upcoming taker fees this might make us even more expensive to perform a swap compared to them. This could be countered with lower slippage, to get the same end result, but that would require a higher level of liquidity to achieve this. Could this be included to make it a real fitting format which gives us an edge in the exchange-wars to come?
• if we have an algorithm determining our incentive gauges, would we still need governance proposals to do it? Or can we cut back on the amount of proposals and simply only bring something to governance if we need changes to the algorithm itself.

[HathorNodes]

Hey, thanks for the comments! To start, what’s being put on chain is in a finished and ready to go state. This kind of program never has a final version if that makes sense. Part of what’s being proposed is the continuous monitoring and improving of the process via working group. The needs of the protocol could change over time. As an example, the community could decide to maximize liquidity on Osmosis as opposed to minimize the number of incentives emitted. Other dApps could join Osmosis that have particular liquidity needs. These aren’t things that indicate the current optimization process suggested is incomplete. They’re just further tunings that keep the algorithm inline w/ the protocol’s needs.

Supercharged Liquidity: They won’t break the program, I’ve tested it w/ the existing SCL pool already. As SCL becomes more mainstream, we can take advantage of its capital efficiency. That potentially reduces healthy liquidity levels needed for SCL pools.

External Incentive Matching: We currently do a partial match on incentives. I’m suggesting making it 1:10 match as its simpler and isn’t costly. The other question I had is regarding proposals for incentive matching. We can automatically match incentives once every month w/out governance. If the community prefers manually approving the matches, that’s fine as well! I’ve gotten mixed feedback on if automatic incentive matching is preferred so I’m hoping to get thoughts on that.

Swap Fees: Increased swap fees definitely impact liquidity needed. For Balancer/Classic LPs, I do include the LPs swap fees in the math for liquidity needed. Quantifying the impact of changes to swap fees on volume and liquidity needs is a good idea for further research though!

We still need proposals at the moment. I’m suggesting moving to monthly instead of weekly proposal. Until the backend mechanism for providing incentives changes, we’ll need periodic proposals. Part of the improvement here is larger changes w/ a lower frequency of proposals.

Let me know if you have any other thoughts/questions!

[LeonoorsCryptoman]

Very curious for other comments

[luisqa]

You literally asked all the questions I had. Excited to finally see this come on chain.

[JohnnyWyles]

Really glad to see this come to chain.
While there might be some concerns over how this applies to the new Supercharged pools, the increase in efficiency from those pools may lead to over-incentivization of some pools since it currently targets Classic pool liquidity in Supercharged pools. However, the net change to incentives is a reduction and so should have a positive impact.

As the methodology is refined, then it can only improve as it adapts to the new pool structures.

[RedRabbit33]

So I’ve mentioned the Toronto Stock Exchange (TSX) cross-subsidization of liquidity a few times now as an evidence based program that I strongly believe is worth exploring to improve the efficiency and effectiveness of liquidity incentive spending. (Six of one, half a dozen or the other, whether it is called a cross-subsidization of liquidity or cross-incentivization of liquidity doesn’t really matter, though I admit a cross-incentivization of liquidity program sounds more appealing and probably easier to sell than a cross-subsidization of liquidity program.)

In their study of the TSX cross-subsidization of liquidity (aka cross-incentivization of liquidity), Foley et al. (2023) right off the bat identify one of biggest challenges to efficiency exchanges face, whether it be a ‘TradFi’ stock exchange like the TSX, a CEX like Coinbase, or a DEX like Osmosis; endogenous liquidity providers.

From Foley et al (2023):

Personally, I believe Foley et al’s provide evidence that exchanges that provide liquidity subsidies/incentives that attracts both endogenous liquidity providers (aka liquidity providers that allocate their capital to higher volume higher market cap assets) and non-endogenous liquidity providers (aka liquidity providers willing to allocate their capital across a bundle of higher volume/higher market cap assets and lower volume/lower market cap assets) are more capital efficient than those that only provide liquidity subsidies/incentives that attract endogenous liquidity providers.

That being said, it seems rather intuitive that it would be more efficient for Osmosis to provide regular internal liquidity incentives, matched external liquidity incentives, and or SFS to multi-asset liquidity vaults on Quasar such as an OSMO-ATOM-USDC-LIKE and OSMO-ATOM-USDC-CHEQ rather than just the OSMO/LIKE and OSMO/CHEQ liquidity pools.

Additionally, it also seems rather intuitive that it would be more efficient, effective, and economical for Osmosis (with or without the support of LST provider external incentives) to diversify its liquidity incentive and provide liquidity incentives to LST liquidity vaults like the ATOM Pro liquidity vault on Quasar that provides liquidity to the ATOM/OSMO, stATOM/ATOM, and qATOM/ATOM pools, and a yet to be created STARS Pro vault that would provide liquidity to the STARS/OSMO, stSTARS/STARS, and qSTARS/STARS liquidity pools.

Allocating a fixed amount or percent of liquidity incentives to a TWAP Oracle liquidity vault also seems like a simpler, more efficient, and more effective way to achieve and maintain a sufficient amount of liquidity across TWAP Oracle identified pools (i.e the ATOM/OSMO, USDC/OSMO, axlWBTC/OSMO, and axlWETH/OSMO liquidity pools) rather than prescribing that a fixed percent of liquidity incentives dedicated to liquidity pools that fall under the OSMO-Stablecoin category be allocated to the USDC/OSMO pool and a fixed percent of liquidity incentives dedicated to liquidity pools that fall under the OSMO-Major category be allocated to the ATOM/OSMO, axlWBTC/OSMO, and axlWETH/OSMO liquidity pools. It also seems like it i spending a small amount of ProtoRev OSMO revenue would be more efficient and effective (and simpler) than reallocating a small percent of liquidity incentives to provide liquidity incentive to support a TWAP Oracle liquidity vault that would help ensure there is a sufficient amount of liquidity being provided to TWAP Oracle liquidity pools.

Since Prop #567 failed to pass, it seems like it would be politically feasible to pass a compromise proposal that would provide a 47.5-47.5-5 split of ProtoRev OSMO revenue (for example), between burning, distribution to stakers, and utilizing for purposes like providing incentives to liquidity vaults, reducing the cost to stakers to convert tx fees paid in non-OSMO tokens to OSMO, and reducing taker fee dust distributed to stakers.

And with that, I rest my case.

[RedRabbit33]

Very happy to see this!

@HathorNodes

Competitive Slippage Levels

The community requested we lower the maximum slippage levels in Balancer Pools to ensure trading on Osmosis remains competitive w/ other dExes. We’ve reduced the maximum slippage levels from 1% for retail swaps and 10% for whale swaps to 0.25% and 2.5% respectively. These levels can be adjusted as needed.

Quick Questions:
Does this mean the default slippage tolerance setting that users see will be lowered to 0.25%, or will it remain 1% and the 0.25% slippage tolerance be a ‘underneath the hood’ feature so to speak?

This is probably better directed to @JohnnyWyles, but if the 0.25% tolerance is an ‘underneath the hood’ feature, can the feature that Leavana offers where users can save their slippage tolerance setting be added?

[JohnnyWyles]

Are you referring to the default frontend setting?
That would be unchanged by this since it acts as more of a safeguard against high slippage trades.

[LeonoorsCryptoman]

However, the net change to incentives is a reduction and so should have a positive impact.

What will happen with the reduced amount? In the past we redirected it to the community pool, but that was already deemed undesirable from this point forwards. Will the APR for stakers go up? Will be not mint the coins at all?

[LeonoorsCryptoman]

I like this idea and believe it is certainly worth exploring.

Did you consider volunteering for the “Incentives Program working group”? It is a nice idea to have smaller pools on Osmosis also benefit from very big ones. That way Osmosis can become a huge magnet for projects who might get a kickstart that way and have their shot of becoming a big one as well, which in turn opens up possibilities for new small ones to get a shot as well. It can really create a flywheel if applied correctly it seems and make Osmosis a real center of gravity.

[RedRabbit33]

@LeonoorsCryptoman - as a well known and highly respected validator, and the author of the weekly governance update column on Osmosis Community Updates Blog, such a working group would benefit much more from your participation than mine.

@HathorNodes - I do apologize failing to communicate my support for implementing the model that has been developed and proposed additional scope of work that is aimed at further improving the efficiency and effectiveness of liquidity incentive spending.

[RedRabbit33]

So another area I think the incentives working group could look into is if Osmosis could in a cost-effective way compete for a greater share of trading volume, liquidity, users for IBC native small and medium cap tokens like DVPN, CUDOS, and CTK, which are listed on large CEXs and where the trading volume is concentrated, by enabling SFS and or adding incentives in a cost-effective manner.

RE DVPN, CUDOS, and CTK as examples:

DVPN - The majority of DVPN trading volume is on KuCoin which also lists OSMO, ATOM, KAVA, INJ, WAXL, XPRT, AKT, SCRT, BAND, and PSTAKE.

CUDOS - ~20% and ~12% of CUDOS trading volume is on Houbi and KuCoin respectively. Houbi appears to list all the same tokens as KuCoin, plus BLD.

The plurality of CTK trading volume meanwhile is on Binance.

Just something I thought worth mentioning/documenting.

[HathorNodes]

At the moment, the excess will go to the community pool. From a technical standpoint, we can’t do much else. Burning the excess from the community pool quarterly (or distributing it among stakers) are possibile in the long run.

I think once there’s a significantly large excess, we can open that up to community input and perhaps some brainstorming. The Osmos can always be redirected to bootstrapping certain LPs, similar to Redrabbits point of competing for trading volume.

[LeonoorsCryptoman]

I’m a bit worried about the excess in the CP to be honest…

I mean, we kinda literally voted for the new tokenomics quite recently to stop the growth of the CP quite drastically. And now we are back at square 1.

Can you show how much excess we are talking about at this stage?

[HathorNodes]

We’re about to introduce new incentivized pools from the Wormhole integration so that the number may be a bit off, but it should be about 1,000 Osmos/day for the first adjustment. I’ll have a more concrete number once we see how many Solana LPs the community wants to incentivize.

[JohnnyWyles]

Just clarifying that these are still planned to be proposed to governance. Although technically, we never made that requirement of new incentive proposals, we just have the proposal requirement to prevent incentive adjustment proposals from failing, as some failed in the early days when there was no trading data behind choices.

Governance should still need to explicitly state that the incentives group can allocate incentives as the algorithm sees fit. I see this as a potential expansion to this current working group’s role in the future.

[RedRabbit33]

I do think a follow-up proposal could be very useful here as there are several things that would be very useful to clarify and codify. I also think there is an opportunity to kill multiple birds with one stone here.

At this moment, I see such a proposal including the following things:

• clarifying the role, responsibilities, and deliverables of the working group

• have the KAVA RISE working group that is being proposed be a subgroup under this working. (If this working group is going to extend longer than 3 months, I think it makes sense to merge the two groups to align efforts)

• increasing the number of working group members. (I would personally like to see a few more members added to this group and the KAVA RISE group. Why? DE&I- Diversity, Equity, and Inclusion. Why does DE&I matter? Because DE&I = Better Decision Making. A 5, 7, and 9 member working groups provide the opportunity to exponentially increase diversity, equity, and inclusion - and better decisions - at little additional cost. A slightly larger working group that is more diverse and inclusive can also improve internal and external accountability and transparency. Personally, I would like to see @LeonoorsCryptoman added to both groups.)

• provide the working group with an operational budget for things like governance proposal deposits (e.g. 4,800 OSMO which would be equivalent of having 3 governance proposals uploaded at once).

  • also certain working group members likely deserve a stipend. Chaos and Hathor’s time may still be covered by OGP funding, and your time by the foundation, but not all community members are like AllNodes, which can afford to volunteer their time that in my professional opinion I would expect members need to be dedicating to these working groups.

[LeonoorsCryptoman]

But I guess we will only update incentives once a month, right?

So between proposals there are no updates to the incentives since we do not have proposals for it to update the gauges.

The only changes we possibly would see is when the algorythm receives an update by learning on the job from the working group. (at least, that is my understanding)

[JohnnyWyles]

I plan on using “bootstrapping” proposals as normal incentive inclusions going forward.
As Gauge 0 (community pool) gains the saved incentives we can directly cut into this for these without impacting other pool’s allocations as bootstrapping has done in the past.