StakeWise V3 Liquidity - SWISE

[Jstar]

As mentioned, we are in discussions with market makers, so OTC routes are available there.

The routing has long been an issue. We’ve had numerous potential investors unable to buy SWISE due to high slippage on aggregators over the past year and we often have people on Discord asking about why they cannot buy SWISE in any size without slippage.

Agree that there are extra considerations for LPs when using concentrated liquidity. All we can do is try to educate users. Rocket Pool has never provided any incentives to LPs for RPL and they have managed to provide quality concentrated liquidity on UniV3, quality enough for them to be listed on all major exchanges without a market maker. For context, every exchange we are speaking to requires us to get an MM because our DEX liquidity is not sufficient - something has to change.

[ottodv]

@Jstar

The routing has long been an issue.

Again you state this as fact. But I haven’t seen proof. The “proof” you provided in your opening post wasn’t the result of routing issues but of market depth/liquidity limitations that are normal in a small market cap token.

So again, can you show us proof of the routing problem without conflating it with the liquidity limitation in the sETH2-SWISE pool?

@Jstar

numerous potential investors unable to buy SWISE due to high slippage on aggregators over the past year

Probably wasn’t due to routing issues, but rather liquidity limitations in the pool.

[kiriyha]

Hey @ottodv appreciate your thoughts on the topic - we had the very same deliberations for months, as @Jstar said. Unfortunately, routing is a serious issue and the the proof is below.

1st image is entering 100 ETH worth of interest into 1inch, 2nd image is the same but on Uniswap. Routing obviously fails on 1inch, leading to 11 percentage points larger slippage.

Hope this clarifies it. We wouldn’t be pushing for something we know is false, or making public claims about it. Routing issues are tough to avoid if the token is paired against osETH in the very first innings of its existence, so we propose ETH.

[ottodv]

@kiriyha

Routing obviously fails on 1inch,

Yeah, 1inch sucks, it routes it through an ETH-SWISE pool.

This is basically 1inch failing to deliver the promise of the best and most efficient price to its users.

I don’t think we should be jumping through hoops to compensate for 1inch’s shortcomings.

Instead warn people not to use 1inch.

I’d much rather build a tab in the Stakewise app that routes the transaction properly. Just like the reinvestment tab.

[kiriyha]

I agree with the sentiment, but in practice usually $SWISE gets the blame for being illiquid / high slippage, rather than 1inch. I am the person who walks people through the routing issue and how to avoid it via support channels, and most of the time the routing issue / slippage ends up being a hindrance to people’s willingness to buy the token. Hence, as much as I like the efficient approach with the osETH-based pool, my take is that it’s best to deploy an ETH-based pool in the beginning and move liquidity to osETH-based pool over time, in order to ensure steady trading in SWISE without issues.

[Archer]

As @Jstar and @kiriyha mentioned there is definitely a routing issue. The vast majority of DeFi users stopped interacting directly with DEXs and instead, they use DEX aggregators. 1inch has by far the largest market share when it comes to DEX aggregators (~70%), so it is important to be pragmatic and acknowledge that if these users are excluded SWISE is severely hindered in terms of exposure.

Even if we look at other DEX aggregators using Defillama’s Meta-Dex aggregator, it is possible to observe that 1inch, Cowswap, 0x, and Kybeswap, all fail to properly route ETH<>SWISE (the exception being Paraswap, but again it is necessary to normalize this versus its market share).

That being said, I believe that later on, once osETH is sufficiently liquid, a complimentary SWISE/osETH Balancer pool can be a good option to diversify SWISE liquidity and reinforce StakeWise’s efforts for osETH to become a unit of account. Assuming a 50/50 ratio, this pool could potentially benefit from Balancer’s Core pool status if paired with osETH thus facilitating the long-term incentivization of SWISE liquidity.

One last thing to take into consideration is that with the current market conditions, the cost of liquidity for volatile pools is extremely high, as such, the opportunity cost of SWISE/osETH versus SWISE/ETH isn’t that relevant when compared to the total yield that the pool should require to attract liquidity. We tend to imagine that LPs are perfectly rational economic agents but in reality, marginal APR differences rarely cause behavioral differences.

[ottodv]

@Archer

it is possible to observe that 1inch, Cowswap, 0x, and Kybeswap, all fail to properly route ETH<>SWISE

That doesn’t really plead for those aggregators. If it happens with Swise it’s happening with many other tokens. Then these aggregators are just scams - costing people a lot of money.

[ottodv]

@kiriyha

I am the person who walks people through the routing issue and how to avoid it via support channels, and most of the time the routing issue / slippage ends up being a hindrance to people’s willingness to buy the token.

The conflation of the two issues isn’t helping here. I suppose once people know where to do the trade, it’s the slippage that stops them.

This is not related to ETH vs sETH2(osETH is the future).

Add: Can’t do a new post so adding it here:

My request to the core team is this:

What is the volume of a trade you want to facilitate without significant price impact? And what’s your definition of significant price impact?

Let’s have some concrete targets/goals.

[ottodv]

@Archer

it is possible to observe that 1inch, Cowswap, 0x, and Kybeswap, all fail to properly route ETH<>SWISE

I randomly picked another than 1inch from your list and got this on Kyberswap:

Versus the same on Uniswap:

Maybe it’s just me, but I fail to see the “routing issue” here.

(Other than 1inch which clearly can’t route properly.)

Paraswap, also seems to get it right:

[kiriyha]

Please try with 100 ETH - a 10 ETH order can be routed through the ETH/SWISE pool somebody set up on Uniswap V3 without much slippage because it’s a relatively small amount. It’s actually the route that both aggregators you posted as well as Uniswap route through. I am currently away from laptop but my hunch is that the issue will persist.

[ottodv]

@kiriyha

Please try with 100 ETH - a 10 ETH order can be routed through the ETH/SWISE pool somebody set up on Uniswap V3 without much slippage because it’s a relatively small amount.

They look quite similar.

Seems like Kyberswap routes it properly.

[Archer]

Kyberswap routes this through ParaSwap, you can check below. That’s the reason why LlamaSwap doesn’t display the Kyber router (didn’t check Kyber individually but they’re just redirecting you to ParaSwap).

LlamaSwap is an aggregator of DEX aggregators, it’s great for quick comparisons between different aggregators and gives you the best quote, I wish that this was more popular. Unfortunately, ~70% of users just go straight to 1inch.

[ottodv]

@Archer

Kyberswap routes this through ParaSwap, you can check below. That’s the reason why LlamaSwap doesn’t display the Kyber router (didn’t check Kyber individually but they’re just redirecting you to ParaSwap).

Isn’t it odd that Llamaswap doesn’t show Kyberswap’s correct rate - the one that Kyberswap shows when you go there directly (which it routes through Paraswap)?

We can conclude that 1inch sucks, and paraswap works great.

I don’t think we should be covering up 1inch’s failures. Instead build a Swise token tab on the Stakewise.io site, which guides people to the best way to buy Swise tokens. Maybe even like the reinvest tab.

[Jstar]

I don’t think we should be covering up 1inch’s failures. Instead build a Swise token tab on the Stakewise.io site, which guides people to the best way to buy Swise tokens. Maybe even like the reinvest tab.

I would agree if the majority of people came through the StakeWise UI to trade SWISE, but that is most certainly not the case. Instead, we would be cutting SWISE off from the majority of DEX aggregation flows and not fixing this before such a major protocol upgrade would be a mistake.

Routing aside, there is another key point to mention here: pairing against ETH mitigates any uncertainties during the transition phase from sETH2 to osETH.

osETH is not yet live and thus it is impossible to pair SWISE with osETH ahead of the V3 launch. There is also no guarantee that osETH liquidity will be sufficient for the main SWISE pool in the months following launch. Keeping SWISE-sETH2 pool live for months after V3 launch also doesn’t make sense and is risky as the sETH2 supply and liquidity is expected to dry up as people migrate to V3.

Of course we want osETH-SWISE as our main pairing, but that is not possible right now. SWISE-ETH solves illiquiity risks during V3 migration and the routing issues. We can then explore an osETH pool ASAP once it is viable (hopefully by EoY).

[ottodv]

@Jstar

I would agree if the majority of people came through the StakeWise UI to trade SWISE, but that is most certainly not the case. Instead, we would be cutting SWISE off from the majority of DEX aggregation flows and not fixing this before such a major protocol upgrade would be a mistake.

I doubt this, most people will visit the website of the project. I certainly visit the website of any project I am considering investing in.

@Jstar

Routing aside, there is another key point to mention here: pairing against ETH mitigates any uncertainties during the transition phase from sETH2 to osETH.

osETH is not yet live and thus it is impossible to pair SWISE with osETH ahead of the V3 launch. There is also no guarantee that osETH liquidity will be sufficient for the main SWISE pool in the months following launch. Keeping SWISE-sETH2 pool live for months after V3 launch also doesn’t make sense and is risky as the sETH2 supply and liquidity is expected to dry up as people migrate to V3.

Those are valid arguments.

@Jstar

Of course we want osETH-SWISE as our main pairing, but that is not possible right now. SWISE-ETH solves illiquiity risks during V3 migration and the routing issues. We can then explore an osETH pool ASAP once it is viable (hopefully by EoY).

So can we have an agreement to launch (not just explore) a osETH-SWISE pool as soon as possible after the migration to V3? With at least the same subsidy as the ETH-SWISE pool.

[Jstar]

So can we have an agreement to launch (not just explore) a osETH-SWISE pool as soon as possible after the migration to V3?

I think this is absolutely fair given it is within the protocol’s best interest to pair SWISE with osETH asap, but it is important we are on the same page as to what needs to be in place before we can launch this pool. The two things that come to mind are:

A) Sufficient osETH liquidity

We do not need crazy levels of osETH liquidity to support a SWISE pool, but I think it would be fair to aim for a pre-defined threshold. For example, ~$15M (~9k ETH) TVL in the main osETH-ETH pool given there is around $5M in liquidity in the current SWISE pool. Arbitrary, I know, but you can see where I am going.

B) Path to resolve routing

This one is going to be more problematic. Let’s just focus on 1inch here given their dominance in DEX aggregation volumes. 1inch has a set list of ‘connector’ tokens (ETH/DAI/USDC/USDT) that its algo uses to calculate routing. The reason why the SWISE-sETH2 pool is not routing properly is because sETH2 is not a ‘connector’ token. 1inch are very reluctant to add new tokens to that list. Many teams have been trying, incl. Balancer, and even stETH/wstETH are not added.

There might be other solutions. The Balancer team suggested that we experiment with a nested liquidity pool, where we pair SWISE with the BPT for the osETH-ETH pool. 1inch has been able to route effectively through other such pools (GHO/3pool BPT, for example). That solves the routing, but it leaves SWISE only partially paired with osETH and adds complexity to LPs.

To conclude
In short, there is no quick fix to B. If we decide to proceed with an osETH-SWISE pool after only solving for sufficient osETH liquidity (A), then my question is what value does this osETH-SWISE pool bring? Granted it would provide some utility to osETH and SWISE holders, giving them a way to farm SWISE, but if it is not going to materially improve the liquidity and trading efficiency of SWISE, then I do not see why the protocol should be paying for it.

With at least the same subsidy as the ETH-SWISE pool.

Could you please explain the rationale behind this?

[ottodv]

@Jstar

The Balancer team suggested that we experiment with a nested liquidity pool, where we pair SWISE with the BPT for the osETH-ETH pool.

That’s sounds like a good idea. The osETH-ETH pool is there anyway. And I suppose this means SWISE can be traded with both ETH and osETH through this pool.

Ideally we would have an osETH-bb-a-WETH pool some time in the future though. Which would mean we’d have to redo the whole pool thing again.

@Jstar

Could you please explain the rationale behind this?

Just for balance.

[Jstar]

Awesome, sounds good. So would it be fair to add the following statement to the SWISE liquidity proposal?

» StakeWise/SLC to actively explore an osETH and/or osETH-BB-a-WETH pairing as soon as possible with the aim to fully migrate incentivised SWISE liquidity away from the SWISE-ETH pool. The caveats here are:

1. this can only be feasible once osETH liquidity is sufficient and
2. the routing issue is mitigated, for example via the use of a SWISE <> osETH-BB-a-WETH pairing. Consequently, there will likely be a situation where StakeWise has both a SWISE-ETH pool and a SWISE-osETH(osETH-BB-a-WETH) incentivised in parallel to test the new pool and to safely facilitate the migration of liquidity.

[ottodv]

Yes.

Side note I think it’s likely best to revisit the setup after we know if we want to use boosted pools (or not). Just to avoid migrating pools too often.

[Jstar]

Snapshot to ratify the above liquidity strategy is now live - vote here.