This proposal asks that the incentives program migrates from incentivizing WBTC.axl pools to IBC native WBTC pairings. This proposal directly moves half of the incentives from WBTC.axl pairings to WBTC pairings with the other half being moved at the next routine incentive proposal.
Background
With Proposal 604, Osmosis governance has recognized IBC native WBTC minted on Osmosis as the canonical version of WBTC.
This status comes with the promise that the canonical status of WBTC will receive higher incentives than the non-canonical version.
This proposal would cause the transfer of incentives from the currently incentivized WBTC.axl volume splitting gauges to the newly created WBTC volume splitting gauges over three weeks, culminating in removing the WBTC.axl pool from the incentives system.
This proposal directly transfers half of the current OSMO incentives from the OSMO / WBTC.axl pool to a combination of the OSMO / WBTC and WBTC / STABLE Volume Splitting Gauge groups.
This proposal also performs a routine move of incentives from individual pools to the VSG created in Proposal 724.
The remaining incentives in the OSMO / WBTC.axl group and the WBTC.axl/STABLE group will be moved to the OSMO / WBTC and WBTC/STABLE grouping in the next routine incentives proposal, expected at the start of March, meaning that both pools will receive a share of incentives for two to three weeks.
Liquidity for the WBTC.axl asset will be maintained by the incentivization of a WBTC.axl/WBTC pool as well as unsubsidized swap fees.
| Pairing |
Current Daily OSMO Allocation |
This Proposal Allocates |
Allocation after next Routine Proposal |
| OSMO / WBTC.axl |
1894 |
947 |
0 |
| WBTC.axl / STABLE |
111 |
111 |
0 |
| OSMO / WBTC |
150 |
624 |
1571 (Subject to normal Adjustment) |
| WBTC / STABLE |
250 |
723 |
834 (Subject to normal Adjustment) |
Target on-chain Date: 12th February 2024
How will this relate to nBTC which should be available in roughly 2 weeks?
1 Like
It won’t.
WBTC and nBTC are different assets. Any nBTC liquidity that we incentivise would be subject to a totally different proposal, but WBTC is the most widely used representative in DeFi right now.
1 Like
Maybe this would be a good opportunity to transition wBTC incentives to a wBTC/USDC pool…? Because isn’t that the ultimate goal?
Trading against USDC would provide a much better user experience. For example, setting ranges in the wBTC/OSMO pool is very difficult, because both tokens are volatile. You can fall out of range if wBTC moves or if OSMO moves. This is why on pretty much every other DEX in crypto, tokens are paired with a USD stablecoin.
I propose we amend this proposal so that the incentives allocated to wBTC go to a wBTC/USDC pool.
1 Like
That sounds like a good idea indeed 
I agree that this is the end goal although I don’t think we want to totally remove incentives from OSMO pairings while other incentives are being used.
The path I was intending to propose was:
- Move incentives from OSMO/WBTC.axl → OSMO/WBTC
- Add incentives on the WBTC/USDC pool (And other non-osmo pairings)
Bringing back the discussion for auto-staking of liquidity incentives since this is far more relevant in the post-bonding Supercharged pools with more liquidity freedom and less incentive to interact with OSMO for new participants.
Happy to modify this proposal to split some of the WBTC/OSMO incentives off to a stable pairing to get that going if it has support.
I guess you probably know best, because you have the most comprehensive view of Osmosis, but my perspective is simply that:
-
As a trader, currently I’m no longer willing to trade BTC on Osmosis. I want to trade BTC <> USDC, which I think is what most people want. That now costs 0.6% per swap (I think), because you have to trade through two pools. Given this high fee along with the low BTC liquidity on Osmosis, and it makes more sense to use other DEXes - even for small amounts
-
As a liquidity provider, I’ve never been willing to provide liquidity for BTC on Osmosis. This is simply because it’s very difficult to pick a good range, because the volatility of BTC and OSMO are factors
Simply speaking from my personal perspective, pairing BTC with USDC would solve both these problems. If there were significant BTC/USDC liquidity on Osmosis - say $2M - I would personally be willing to trade BTC on Osmosis, and maybe even LP a little.
It’s true that pairing BTC directly with USDC would remove some utility from OSMO, but I think at this point the “utility” of OSMO as the common pair denominator of the DEX is hampering the growth of Osmosis. And beside, the main reason to hold OSMO is now present and expected revenue generation from the taker-fee. Additionally, perhaps OSMO may soon have utility from offering a trading discount for staking, as Sunny and others have discussed.
And with regard to splitting the BTC incentives between BTC/OSMO and BTC/USDC - I’m personally in favor of concentrating liquidity in as few pools as possible. If we split incentives like these, then there will be BTC trading liquidity in:
- axl.BTC/OSMO (xyk)
- axl.BTC/OSMO (conc liq)
- BTC/OSMO (conc liq)
- BTC/USDC (conc liq)
In my view, the recent proliferation of pools on Osmosis is making the trading experience very difficult. It’s far better for the sake of user experience to have as few pools as possible.
At this point - now that we have Cosmos-native wBTC and USDC - Osmosis has the chance to attract serious traders and LPers. And the way to do that is to incentivize one simple BTC/USDC concentrated liquidity pool, so that it can have as much liquidity as possible.
Anyway, this is just my perspective.
1 Like
Very nice to see the " As a XXX, …" in here, since that is a really powerful tool to drill down to what you want to have. I like it.
Thanks also for putting in the high swap fee for going through 2 pools. That is exactly where the multi-hop once was meant for, to make Osmosis competitive on that field, without having the need of all direct pairings. We have lost that advantage, but I still don’t understand why.
OSMO has been bad for every paired coin in this bearmarket. It might be time to leave the OSMO-pairings in general. For me going to only BTC/USDT or USDC pools would certainly be something I would support. This would surely benefit traders, since you remove a lot of risk from being in the LP or trading the asset.
1 Like
Agreed with John Galt. Having pairs of crypto/osmo is kind of interesting because you were able to trade between two different cryptos and liquidity could be shared within those routes. However with the implementation of taker fee it’s prohibitively expensive to do a double-hop route so now single hop is pretty much the only option. But most single-hop pools barely have any liquidity (Compare ATOM/OSMO supercharge vs ATOM/USDT supercharge…). I also think the number of pools is kind of insane. Should pick 0.2% or 0.05%, not have double the amount of pools and fragmented liquidity when the functionality of the pools is essentially the same.
2 Likes
I think until BitGo / WBTC come up with something similar to CCTP, the canonical WBTC on Osmosis should actually be an alloy between IBC native WBTC and WBTC.axl
But why? All that does it give you unnecessary exposure to Axelar.
Native WBTC as the canonical WBTC = exposure to Bitgo and Osmosis.
Alloy of native WBTC and axlWBTC as the canonical WBTC = exposure to Bitgo, Osmosis, Axelar, and Ethereum.
As a user, I want to trade Cosmos native USDC and Cosmos native WBTC. Personally, I’m looking forward to not having to use non-Cosmos tokens on Osmosis.
2 Likes
It kinda feels like the derivatives being composed of different versions of the same asset.
Transmuter makes the whole trading experience better imo, and might deal with the fragmented liquidity underneath as well. So for me it would more be the question when we will be able to experience the full advantages of Transmuter on the front-end to tackle a couple of the new (and old) issues with low liquidity of assets.
Interoperability is the key here I believe - WBTC on Osmosis you can only get by:
- Interacting with a KYC merchant and minting directly on Osmosis, likely in bulk
- Interacting with a CEX to withdraw directly to Osmosis.
Both of these require off-chain operations to perform and so are less than ideal.
If I have WBTC on Ethereum and want to come to Osmosis then I have to do one of these things, or bring WBTC via Axelar to Osmosis and swap somehow.
Options here are:
- CL pool, I pay a swap fee and incur some slippage for doing this
- Transmuter v1 pool, no fee, but an altruistic participant has to ensure both sides remain liquid.
- Transmuter v2 Alloyed asset, no fee, but the representative asset gains exposure to bridge security issues based on how much that route is used.
I think we should have native “WBTC” as the asset on Osmosis, and use WBTC, WBTC.axl, nBTC and any others in an Alloyed “BTC” token to get the best of both worlds. That way if someone just wants exposure to WBTC as in other platforms they can.
1 Like
Bumping this topic due to the rewrite and WBTC liquidity becoming initially available on Osmosis.
By the time we have VSG gauges live (Create Volume Splitting Gauges for Native WBTC pools) this should be ready to propose.
Have adjusted the original proposal to:
- Use VSGs instead of single pools since those weren’t available at the time of writing
- Rather than a 4:1 split, the first move allocates 25% and 25% to OSMO/WBTC and WBTC/STABLE with the second moving entirely to OSMO/WBTC, resulting in a 3:1 split.
How far out are Alloyed Assets?
Furthermore; do you intend to move all incentives at once? Or is there a grace period in between where we also stick with wBTC.axl to see how demand and availability moves?
We could technically launch Alloyed assets now - but Assets are fixed in place with v2.
v3 is in audit that enables modifying which assets are included by governance but not sure on timeline yet.
The grace period is in the text, there will be around 2 weeks where both get incentives, however, Osmosis should really be prioritising the natively issued version for use. USDC.axl has remained in the top 10 in terms of liquidity after no longer receiving incentives and so we should be able to move all incentives to the new version while leaving a composability pool in place.
Clear!
Probably overlooked the grace period 
I do agree in the end the native version should be prioritized, since in essence there should be less bridging risk, right?