This proposal enables the list of potential uptimes usable by incentive gauges on Osmosis. These are limited to the following due to accumulator requirements.
This proposal does not directly enable a specific Uptime incentive for use across Osmosis but enables this to be set by both governance and external incentive providers.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Forum Thread: https://forum.osmosis.zone/t/proposal-for-uptime-based-incentives-on-supercharged-pools/561/