Proposal for Uptime-based Incentives on Supercharged Pools


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.


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.

1 Like

This is an excellent proposal, and at first glance a WIN-WIN-WIN situation. Very attractive to LPers (they can get bonus rewards should somebody exit early), traders (better liquidity), and to delegators (protocol revenue). I can’t help but feeling bullish!

However, I’d like to point out a possible scenario: Assuming a pool requires a position to be within an active range for 7 days, what if the position falls out of range for some time and then goes back in range? Would it reset the active time to zero again? Even if they are out of range for a single block? Is there a grace threshold for this, similar to validator downtime?

Apart from that concern I guess the objective would be met either way. This idea’s “reward liquidation” would benefit those who are still in an active position, incentivizing wider liquidity, as well as those who take less risk. There would be a risk-reward equilibrium for LPers. Higher risk = higher reward. Currently the only “risk” for taking a tight range is having to manage the position in order to be in range.

With this proposed change the risk of loosing rewards for tight ranges increases significantly, and is given to your average-joe user who just wants a good investment.

Locked as duplicate of

1 Like