Proposal for Uptime-based Incentives on Supercharged Pools

Overview

Concentrated liquidity has a number of key differences from Osmosis’s Classic and Stableswap pools that make it require a new mechanism for distributing incentives. In general, the design space of incentive mechanisms for concentrated liquidity DEXs is extremely underexplored, so this is a great opportunity to break some new ground in the broader design space of order-book-style AMMs.

Below, we outline the status quo approach for CL incentives that Osmosis currently has implemented, as well as our proposed mechanism that leans on the notion of uptime to reward non-mercenary LPs without requiring lock-in through a bonding-like system.

Target Properties

As a starting point, it’s important to understand the properties of a healthy liquidity pool. These are all, of course, properties that become self-sustaining once the positive feedback cycle between liquidity and volume kicks off, but for the sake of understanding what exactly it is that we are trying to bootstrap with incentives it helps to be explicit with our goals.

Liquidity Depth

We want to ensure fees and incentives are being used to maximize liquidity depth at the active tick (i.e. the tick the current spot price is in), as this gives the best execution price for trades on the pool.

Liquidity Breadth

It is critical that as we roll out concentrated liquidity, there is an incentive for there to be width in the books for our major pools. This is to avoid the scenario where the liquidity in the active tick gets filled and liquidity falls off a cliff (e.g. when there is a large price move and active tick LPs get bulk arbed against). It is important for our liquidity base to be broad when it is low until our CL markets mature and active LPs begin participating.

Liquidity Uptime

We want to ensure that the active tick is not only liquid, but that it is consistently liquid, meaning that liquidity providers are incentivized to keep their liquidity on the books while they trade.

Specifically, we want to ensure that idle liquidity waiting for volume does not sit off the books with the goal of jumping in when a trade happens, as this makes Osmosis’s liquidity look thinner than it is and risks driving volume to other exchanges.

While just-in-time (JIT) liquidity technically benefits the trader on a first-degree basis (better price execution for that specific trade), it imposes a cost on the whole system by pushing LPs to an equilibrium that ultimately hurts the DEX (namely that liquidity stays off the books until a trade happens). This instance of Braess’s paradox can be remedied with mechanisms designed around rewarding liquidity uptime.

Current Standard: Pro-rata in Active Tick

The current status quo for concentrated liquidity incentives is to distribute them pro-rata to all LPs providing liquidity in the active tick. With some clever accumulator tricks, this can be designed to ensure that each LP only receives incentives for liquidity they contribute to the active tick.

The primary problem with this approach is that while it incentivizes liquidity depth on the active tick, it provides no incentive for LPs to provide this liquidity consistently or across broader price ranges. Specifically, it advantages LPs who keep their liquidity off the books until a trade happens, ultimately pushing liquidity off of the DEX and creating ambiguity around the “real” liquidity depth. This forces traders to make uninformed decisions about where to trade their assets (or worse, accept worse execution on an inferior venue).

In other words, instead of having incentives go towards bootstrapping healthy liquidity pools, they risk going towards adversely pushing volume to other exchanges at the cost of the DEX, active LPs, and ultimately traders.

Our Proposal: Uptime-based Incentives

To achieve all three of the properties outlined above (and address the issues with status quo incentives), we introduce the notion of uptime. This addition is intended to allow incentive providers to incentivize not just liquidity depth (as they could with status quo incentives) but also uptime, which then also implicitly achieves breadth. In short, uptime-based incentives allow for a single set of incentives to provide liquidity depth, breadth, and uptime to a pool.

Incentive Provider Perspective

We allow for incentive creators to specify a “minimum uptime” from a list of supported uptimes for liquidity that they incentivize such that emissions will only be distributed to LPs who have been in the pool for at least the specified period of time. In all other ways, incentives would work as outlined in the “Current Standard” section above.

Liquidity Provider Perspective

Uptime-based incentives are a significant relaxation of our prior mechanism around bonding for LPs. LPs will no longer need to commit to a fixed unbonding period – instead, their positions will automatically become eligible to accrue and claim incentives once they have been in the pool for sufficiently long given the requirements set by the incentive records on the pool (which are constrained to the supported uptimes).

More concretely, while LPs begin accruing incentives immediately upong joining a pool, they are unable to claim them until their position has been in the pool for long enough to qualify.

For example, if a specific incentive requires 1 week of “uptime” and an LP closes their position 3 days after creating it, they will not recieve any incentives. On the other hand, a position that has existed for exactly 1 week and then exited will get a full week of rewards.

It is important to note that LPs are still able to exit the pool whenever they want, just that if they choose to exit before their position satisfies the uptime requirements for each of the incentives they are accruing, they will simply forfeit those incentives to the other LPs in the pool.

Technically, any change to a position will trigger such a reset, including adding to, removing, or moving positions. Thus, common flows such as compounding positions will need to be abstracted as creating multiple positions unless and until this mechanism is extended to accommodate such flows more cleanly without compromising on the properties outlined above.

FAQ

Why not do a bonding-based system with shorter durations?

Bonding, or any form of hard LP lock-in for that matter, becomes problematic in CL-style systems where LPs need to move their positions on a somewhat regular cadence to remain in range and profitable. Even a short unbonding period would mean that we are forcing LPs into a position where they have very little recourse if the price moves out of their range.

This is in addition to the fact that bonding is one of the least popular features among LPs, likely due to the “sitting duck” lock-in it creates in capital flight scenarios.

The mechanism described in this proposal gets all the benefits of bonding-based systems, but without the LP lock-in.

What happens if an LP puts liquidity outside the active tick? Will they still get incentives?

Liquidity outside of the active tick will not receive incentives. Much like the status quo concentrated liquidity incentive design explained above, positions will only accrue incentives proportional to the amount of liquidity they are contributing to the active tick.

How does uptime increase liquidity breadth?

Since each position that wants incentives needs to commit to a specific tick range for a set period of time, there is necessarily a positive correlation between how high the minimum uptime requirement is and how wide the LP’s tick range needs to be if they expect to be profitable.

7 Likes

Cool idea. I’m in favor of it.

It seems to me your incentive framework is a trilemma, similar to the decentralization trilemma and scaling trilemma.

So the depth, breadth, uptime dynamic is a zero-sum game. According to this proposal, Osmosis would trade off some depth in exchange for better breadth and uptime. I think it’s a good trade-off, because as you mention it would make traders feel more comfortable to see liquidity on the books.

Some clarifying questions:

I assume this only applies to incentives, right? If so, LPers targeting swap fees would still be able to jump in and out of the book without forfeiting rewards, allowing them to tightly concentrate and provide depth.

Would there be different tiers for uptime? Eg, you can claim 50% of your earned incentives if you achieve three days of uptime, but you get the full 100% if you achieve seven days of uptime.

Hopefully, new tokens launching on Osmosis won’t have this uptime requirement. For example, I think the uptime requirement would have been detrimental to the TIA launch, because no one knew where the price would settle. So I would recommend that future new tokens - such as NAM, LVN, etc - have no uptime requirement for the first couple weeks.

Lastly, when do you expect this could be implemented?

3 Likes

There has also been some discussion on this thread about implementing such a model: Signaling proposal to implement minimum uptime of 1 day for a CL position

I think the repercussions of only incentivising depth are shown particularly in stable tokens. When USDT first launched the liquidity was insufficient to hold it at peg and large transactions triggered a depeg due to the liquidity all being focused on the minimum possible tick range.
By setting an uptime requirement we lose some capital efficiency for liquidity while being far more resilient against depeg events, especially global ones which won’t be arbitrage away quickly. The efficency is still far better than classic pools even with a wider distribution around tick.

I believe this should be in place for all tokens but at a much shorter uptime requirement. Celestia launch might have been volatile, but that just encourages providers to provide a wider positions rather than constantly following the tick around. This results in a more stable trading experience since liquidity is relatively constant. The uptime requirement should be measured in minutes, hours at most, rather than days in my opinion.

3 Likes

Correct — fees would continue to be pro-rated with the standard model. It’s worth keeping in mind that incentives are a qualitatively different thing than fees: they are an expense paid by the protocol to subsidize and bootstrap positive-sum behavior. Thus, we can make incentives more configurable to nudge our markets towards more favorable equilibria without hurting the underlying market structure (as similar constraints on fees might).

Yes.

One important clarification on the intended design: there would be a broad set of supported uptimes that can be chosen from when creating incentive gauges to supercharged pools. Thus, for external incentives, this would simply provide an additional (and for some pairs, very critical) lever. The exact uptime requirements should be configurable across a range of seconds to weeks, although I suspect most of the utility will be in the shorter durations.

For the sake of simplicity, we would likely advocate for putting all internal OSMO incentives on a single short uptime (e.g. 60 seconds) that would allow vaults to continue to benefit while making sure liquidity breadth and uptime are part of the equation. For new tokens that have early demand frenzy like TIA, fees dominate returns anyway, and it is important that we ensure internal incentives are spent on bootstrapping stickier long-term liquidity.

This design space is one that we as a team have been thinking about for quite some time (including for designs that build off of uptime as a primitive in clever/novel ways). As a result, we architected the incentives portion of our concentrated liquidity codebase in a way that lends itself to enabling this feature with an extremely lightweight chain upgrade plus a gov prop.

Thus, the majority of the development for this feature is already complete and would essentially just need to be “turned on” in the next chain upgrade. Importantly, the changes would not require state migrations, would have no material impact on chain performance, and were already covered in our original audit process for supercharged liquidity.

3 Likes

@alpin can you also check on the post of @JohnnyWyles ?
For me it feels two different approaches for the same issue, where the other one has been online already for a bit longer and has gathered a little bit more feedback.

Maybe good to see if these 2 approaches can be merged to create one kick-ass solution to make sure we end up with the best option we have?

I am all ears to incentivize longer durations of liquidity. CL might be a good thing, but it is something which also has some disadvantages which we need to tackle with smart solutions like these 2 approaches.

1 Like

My only concern with this proposal is effectively resolved by this comment, but given that this isn’t a certainty yet and @luisqa has put up an alternate proposal to set uptime minimums at 1 day I thought i’d address this anyway.

Uptimes that are exceedingly long (measured in days) will make it difficult to maintain positions that are otherwise highly capital efficient for both traders and the LP. It’s worth noting that with an uptime of 1 day, a huge majority of LPs would have forfeited their incentives this week with the volatility we saw in the market.

LPs should be encouraged to adjust their positions more frequently in events like this. It does the chain far less good to have these LPs wait for 24 hours to move their liquidity. A shorter uptime like the one proposed here will greatly reduce (or eliminate entirely) the instances of a JIT liquidity bot placing a position 100% in the active tick to maximize incentive extraction from the pool.

This would also allow for ranges to be placed more efficiently while still encouraging position breadth. As @JohnnyWyles mentioned, if we want to optimize slightly more for breadth, we could expand this to maybe 10-60 minutes, but anything longer seems unnecessary and so inefficient as to almoat defeat the purpose of having CL in the first place.

2 Likes

While I do find it best to always begin with the KISS premise, I do wonder if a single threshold is sufficient to effectively tune.

A bit more flexibility would also provide a larger space of compromise around concerns that have already been expressed above and in other threads about timeframes.

Maybe it’s just familiarity bias of the GAMM bonding system but what about something like 1 minute, 1 hour, 1 day thresholds for CL where you’re position incentive eligibility ramps up 70%/95%/100%?

Overall, I’m in support of implementing a minimum Uptime threshold for CL incentives eligibility to better bring that JIT liquidity onto the books for improved transparency. Though I think the depth vs breadth aspect of this change will warrant more than a single parameter.

1 Like

In terms of actually what the chain decides:

  • The ability to have uptime-based incentives would work as part of a Software upgrade proposal to fully enable this feature since it can technically remain as is with no uptime incentives.

  • Setting a global default for uptime on existing gauges/changing the incentive distribution to a new set of gauges with an uptime parameter would be another proposal.

We have data for 1ns now, which can be seen to not be optimal. I think we should increase this to 1 minute at first and then increase in increments on one pool to see the impact on breadth. In theory, it should be quite predictable since it should relate to a pairing’s volatility.

I definitely think the worst case should be allowing a user to change their position daily without missing out - which is likely a ~20 hour maximum to allow for varying log-on times.

Agreed on taking small steps. Going from the current 1ns to 1 day is a huuuuge gap which might simply be to big.

Going to 1 minute might indeed already battle bot-liquidity a bit and maybe solve our issue in the first place. Through monitoring it can be decided if we need to test at certain pools to make the time period longer, but that is extremely hard to predict at this point in time.

If this would go on chain for 1 minute, it would have my vote.
Timeline would be a different story, since it would most likely end up at the desk of the developers (which is already quite full :stuck_out_tongue: )

These parameters need setting by governance before one can be chosen.

Going to be citing this thread and text as the proposal, to go on chain after v23 is live.

We are unable to use any parameters except the ones that have been implemented during testing as an accumulator needs to be run for each.

These are:

  • 0.000000001s (Current)
  • 60s (1 Min)
  • 3600s (1 Hour)
  • 86400s (1 Day)
  • 604800s (7 days)
  • 1209600s (14 days)

I will follow up early to mid-week with another forum post to propose the actual time to be used for the default across Osmosis.

Echoing the sentiment expressed by @RoboMcGobo, uptimes longer than (or even at) 60 minutes will likely begin to adversely affect liquidity. As incentives continue to outweigh swap fees, there is a tipping point where liquidity providers will choose to forego moving positions in order to avoid forfeiting incentives as well as incidentally saving costs on rebalancing. This will set a sort of “refresh rate” for price updates, degrading user experience and liquidity efficiency, especially in times of high volatility.

edited to add:
It would actually seem like the premise of this proposal is flawed.

Given that there is a default uptime already of 1ns, it is impossible for a liquidity provider to create and remove a position within the same block, keeping liquidity “off the books”, and earn incentives at the same time. Any JIT liquidity providers would be looking to capture swap fees, which this proposal will specifically allow to continue.

It seems to me that the proposer themself admits that trade execution will be worsened, in return for solving a problem that may not even exist

But would putting it into block 1, earning incentives and removing in block 2 not still hurt the DEX in general? Since the JIT-ish liquidity will reap a lot of the incentives, whereas the more passive liquidity will get less? I do get the idea that it is a potential issue, especially when we start growing even more than we already do.

Maybe it is better to select a couple of pools where we can test to avoid setting a parameter we don’t want all over the place?

Beyond whether an incentive is distributed at all, the question is whether this behavior “wastes” incentives. Adding liquidity and removing it the next block would not earn “a lot” of the incentives, it would earn a proportional share of one blocks worth. As incentives are loaded each epoch and distributed each block they are spread equally over time, whereas swap fees are not, meaning that the share of incentives given to JIT providers (if they even exist) would be relatively small. And by the same token, “non-JIT” providers will end up earning a larger share of incentives and much smaller share of swap fees. In the end this seems to incentivize less efficient liquidity.

I think longer uptimes should be more useful for less volatile assets.
I don’t really see a scenario where we would use 7 or 14 day for typical incentives but it was requested by other integrators.

1 minute seems to be a good setting to start with to impact capital efficiency minimally while not allowing block by block rebalancing to provide JIT liquidity.

Highly correlated assets should probably use a higher uptime as they are less likely to leave a specific tick range, so even a single tick position is likely to remain valid for some time.

I personally think that the sweet spot in terms of the tradeoff between capital efficiency and liquidity will be somewhere between the 1 minute and 1 hour point; however, we are constrained to only these few settings due to performance concerns.

As you are the operator of one of the two main bots that are performing this action in pool 1400, @bananadao, do you have records on your returns and expected impact? My initial modelling looks like Banana vaults will be minimally impacted since your positions last over a minute on average, whereas the other bot creates a new position almost every block.

Querying pool 1400 right now shows osmo1ftrc7zh7wfyhrzpknplygttyp78hgccel7echm - Banana Vault and osmo1st33jpzjm0wdxfne6ggw9s940c0lmvmkh782km - Other bot that adjusts every block each having 49.8% of the liquidity at spot price. Meaning that those two addresses are getting 9% of all OSMO incentives each as they continue to adjust while providing no width in the event of high volatility.

Positions by addresses:
https://lcd.osmosis.zone/osmosis/concentratedliquidity/v1beta1/positions/osmo1ftrc7zh7wfyhrzpknplygttyp78hgccel7echm
https://lcd.osmosis.zone/osmosis/concentratedliquidity/v1beta1/positions/osmo1st33jpzjm0wdxfne6ggw9s940c0lmvmkh782km

Indeed, I don’t find that Banana market making efforts will be much affected by any reasonable minimum uptime. To give a bit of insight into our operations, although super tight ranges are employed, they are calculated based on an average “dex price” which is heavily weighted towards larger liquidity pools, in effect “mirroring” their price. Combined with the excellent work done by the back end team on the new swap router, and the new multi route swap types, this basically allows us a mechanism to provide an amount of ultra efficient, 0% swap fee liquidity that will be preferentially used to enhance the swap output for a vast majority of traders in that asset pair. This is the engine behind the success of pool 1400, volume and taker-fee wise.

The question of liquidity width is another question, and it should be addressed, but uptime doesn’t seem to be to me the way to accomplish it. Instead of trying to solve it indirectly, perhaps incentives could be tied to an actual width minimum or even just reduce the spacing increments (both of which will end up affecting trade execution as well)?

3 Likes

Just to be sure, your counterproposal is to implement a minimum width to be applied to a position before it is considered to be eligible for incentives?
Meaning it can still earn on swap fees, but not on pool incentives anymore?

Does that not still leave the problem of single-tick liquidity which is not beneficial in volatile times? Whereas the minimum retention time kinda forces a wider position, but also to be available for longer which is beneficial for a lot of traders at the same time?
I can imagine this will make the calculations for the needed width more difficult, since it will introduce a couple of new parameters to take into account, but if I read that your average retention already over a minute then it should already be doable.

I do not assume that the minimum retention time will force a wider position. The position does not need to be in range for the whole time, so it is conceivable that a liquidity provider could choose to be in range and earning, for example, 75% of the time in a tight position rather than 99% of the time in wider position, if it is more profitable. This is why it does not directly address the issue of tick width. Whereas an actual minimum width would do just that, while continuing to allow “true” JIT LPs (someone entering the position and exiting in the same block) to harvest swap fees (as was and is the case)

1 Like

Clear!

One thing to take into account though (and correct me if I’m wrong @JohnnyWyles ) is the question whether a feature like that still needs full development.
If I am correct the uptime is already a parameter which we can configure, whereas the width might need development and coding.

2 Likes