Proposal Details

Proposal #737

Passed

Proposal title

Authorize Uptime Incentives Parameters list

Submit time

Deposit end time

Voting start time

Voting end time

Tally result

87.02%

Proposal #737 description

This proposal enables the list of potential uptimes usable by incentive gauges on Osmosis. These are limited to the following due to accumulator requirements.

  • 1ns
  • 60s
  • 3600s (1 Hour)
  • 86400s (1 Day)
  • 604800s (7 days)
  • 1209600s (14 days)

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.

Why are Uptime Incentives needed?

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.

Forum Thread: https://forum.osmosis.zone/t/proposal-for-uptime-based-incentives-on-supercharged-pools/561/

Proposal #737 overview

Total votes
33,135
Voters
33,035
Total deposit
1,600 OSMO

Proposal #737 votes

#

Validator

Account Address

Options
1Stakewolle.com |100% InsuranceYes
2MerkanYes
3Bro_n_BroYes
4CrowdControlYes
50base.vcYes
6EverstakeYes
7a41Yes
8ushakovYes
9PRO DelegatorsYes
10ForboleYes
11Oni โ›ฉ๏ธYes
12CommunityStakingYes
13Coinage x DAICYes
14PRYZM | StakeDropYes
15Kalia NetworkYes
16POSTHUMAN ๐Ÿงฌ StakeDropYes
17Golden Ratio StakingYes
18White WhaleYes
19ObiYes
20binary_holdingsYes
21ECO Stake ๐ŸŒฑYes
22ValidatusYes
23S16 Research VenturesYes
24Informal SystemsYes
25Chorus OneYes
26DAO DAOYes
27Stakely.ioYes
28DSRVAbstain
29COSMร˜STAKEYes
30QuebecYes
31AllnodesYes
32strangeloveYes
33Lavender.Five Nodes ๐ŸYes
34Tedcrypto.io ๐Ÿงธ | TedLottoYes
35#decentralizehk - DHK daoYes
36CryptoCrew Validators โœ…Yes
37AlphaNodes๐Ÿ›ธAbstain
38Simply StakingYes
39Notional.VenturesYes
40Trust NodesAbstain
41InteropYes
42B-HarvestYes
43CrosnestYes
44Swiss StakingYes
45Citadel.oneYes
46CosmostationYes
47StakecitoYes
48MendelYes
49PoS NodeYes
50Sr20deYes
51[Beehive]๐Ÿ‡ฐ๐Ÿ‡ทYes
52KomikuriYes
53Leonoor's CryptomanYes
54Zero Knowledge Validator (ZKV)Abstain
55d3akash.cloudYes
56defiantlabsYes
57Hathor NodeYes
58GATA HUBYes
59SpectrumXYes
60reynisfjaraAbstain
61StakeLab.zoneYes
62Chill ValidationYes
63Nocturnal LabsYes
64ChainflowYes
65jabbeyYes
66CoverletYes
67Interstellar Lounge ๐ŸธYes
68AutoStake ๐Ÿ›ก๏ธ Slash ProtectedYes
69ChainLayerYes
70blockscapeYes
71AUDIT.oneYes
72stake.systems | autocompoundYes
73Silk NodesYes
74Cypher CoreYes
75OldcatYes
76Active NodesYes
77WhisperNode ๐ŸคYes
78MeriaYes
79Node GuardiansYes
80KingSuperYes
81Vitwit (Previously Witval)Yes
82Smart Stake ๐Ÿ“ˆ๐Ÿ“ŠYes
83coinhall.orgYes
84PingYes
85StakeWithUsYes
86FreshSTAKINGYes
87in3s.comYes
88Imperator.coYes
89InterblocYes
90TaxiStakeYes
91ShapeShift DAOYes
92polkachu.comYes
93ChihuahuaYes
94Nodes.GuruYes

View: