Add ATOM/USDT pairings to the Osmosis Incentives Program

Proposal Discussion Liquidity Incentives
1

Add ATOM/USDT pairings to the Osmosis Incentives Program

This proposal asks that the pools comprising the ATOM/USDT Supercharged pairings created in Proposal 579 be added to the Osmosis incentives program.

Background

Pools following the pattern of MAJOR/STABLE category have received no incentives since the category model was introduced in Proposal 233. The Osmosis community had previously chosen to minimize incentives to non-OSMO pools to prevent excessive value leakage.

The MAJOR/STABLE incentives category itself was removed in Proposal 389. This was driven by the multihop mechanism being implemented, which led to the most optimal routing for trades being via OSMO rather than a direct route.

Proposal 530 proposed adding a Taker Fee of 0.15% to all swaps, including each hop, drastically reducing the impact of the multihop discount and making direct routes competitive again.

When a taker fee is introduced in a future software upgrade, establishing non-OSMO pools increases the value capture of the protocol in non-OSMO assets. This has the potential to exceed the value of OSMO spent on incentivizing liquidity to cater to trading. Each OSMO of incentives currently generates around 0.4 OSMO in swap fee value. With Supercharged pools expected to increase the efficiency of fee generation significantly, each OSMO emitted to these pools as incentives may lead to a net positive gain for the protocol and increase the yield for stakers.

This proposal asks for a limited incentivization of these pools, capped to no more than 1% of OSMO incentives in total, at a 1:1 daily swap fee to daily OSMO spend only, similar to how the Stable/Stable category is currently structured.

This would limit the OSMO spend on the pool if the fee generation is lower than expected while preventing the category from taking a large portion of OSMO incentives in this trial period.

The two ATOM/USDT Supercharged pools created in Proposal 579 would then be added to the incentives system at the next routine incentives proposal as part of this category.

Both pools are added to the incentives system to allow the optimal spread factor to be used from the two options of 0.05% and 0.01%. The pools will therefore be incentivized based on their performance. As there is no bonding period for normal Supercharged liquidity, this should encourage the movement of liquidity between the two pools as required to provide optimal trading liquidity. This represents a movement towards the incentivization of pairs rather than pools.

Target On-chain date: No earlier than 14th August 2023

1 Like
2

Just in short; you are requesting to add a MAJOR/STABLE category (important to recognize that we will not see a MINOR/STABLE category to avoid clogging our overviews again :stuck_out_tongue: )?

An interesting experiment which we should surely take.
Also reminds me that we still have to take a decision on the maximum fee we want users to pay in combination with the taker fee.

3

I noticed while posting this that since Hathor’s proposal passed we actually no longer have the category system in place.

Major and Stable assignments still exist (which could be repurposed in future) but as incentives are now assigned based on typical trading amount there is no built in bias towards Major assets, just the inherent bias that higher market cap assets will likely see consistently higher trades.

I also think we should be moving towards incentivising non-OSMO pairs after the taker fee goes live, especially if the inflow from this exceeds the outflow from incentives so I would very much not write off “MINOR/STABLE” pairings.

2 Likes
4

Yeah, in essence the new model will not make a difference between which pairing attracts enough volume to receive incentives.

Should we than not even think further and kinda skip the onboarding of assets in general? And simply implement that when a pool generates more than a certain threshold in terms of trading fees the pool can be included in the incentives program?

That would even further automate it and make it less “subjective”

1 Like
5

Very much in favour of this if you want to dig up the old conversations on codifying incentives. However, I don’t think it is time for this yet.
The problem was gamability. Ideally, we get to the point where incentives are less than the protocol earns from swap fees in a pool, and so gamability is not a concern at all.

6

The best one I can find is this one: